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Bill Ashby, K2TKN 
Dear Gwyn: 
It seems like a long time since we used to have 


you check into our North Central Jersey Tech. nets on 
Sundays! 


Just wanted to drop you a note to thank you for 
forwarding the FADCA BEACON to us. Enclosed is 
a check to cover past postage, etc. and keep it coming. 


I will also take this opportunity to express my 
personal opinions relating to the explosion of numbers 
of packet stations that the Heath-Zenith promotion is 
bound to generate... You may publish any part that 
seems of interest to your group. 


K2TKN has been in three wars on the Ham 
Bands — as WOETJ we helped start NBFM on 75 
meters before there were crystal controlled 2 meter 
rigs — then rode out the jibes and catcalls getting 
SSB accepted on 75 and 20 — then opening up the 
high end of 2 meters with liberated taxi repeaters — 
that was enough, there is just no valid reason not to 
speak out when I see another war starting because of 
packet operation on heavily populated channels. 


I am in favor of trying new modes of communi- 
cation and applaud the VEs and your group’s efforts 
to link widely spaced stations into a working net- 
work... but as violently against setting any form of 
standard (hardware or software) this early in packet. 
We need AX.25 as an entry-level protocol to get new 
stations operational and in contact with their local 
packet group, but it should be well understood that 
AX.25 on AFSK at 1200 baud is about at the techni- 
cal level of spark transmitters and crystal receivers on 
long-wave. Our TNCs and particularly repeaters must 
be kept open for experiments with better protocols. 
Digipeaters (REGENERATORS) operating on local 
net frequencies at 1 to 1 speed ratios are doomed to 
failure just as soon as any real volume of traffic shows 
up. The Pony Express was great but went bust the 
instant a wire was strung along the route! The full 
paged ads promoting sale of packet equipment — 
"Everyone can be a REPEATER OWNER" and 
“automatic Digi-ptr with a few keystrokes" are the 
culprits and should be stood against the wall and shot 
for starting a war. Any TNC or repeater that the 
owner can’t reprogram easily is going to be obsolete 
very quickly in this digital operation. 

We think the next generation of repeaters will 
handle mixed modes of operation (baseband FM and 
SSB for voice and subcarriers for digital) but of 
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utmost importance will be bulletin boards with gate- 
way channels to DMA large blocks of memory to 
adjacent bulletin boards. Getting to this point is not 
going to happen overnight and requires a great deal of 
experimentation that poor protocols may hinder. As 
long as the experienced packet operator understands 
that the pasting and patching that attempts to make 
AX.25 a smart-term with link level 3 to repeater capa- 
bility has not improved throughput of data or resis- 
tance to collision link failure. The real advantage of 
packet is the ability to run many QSOs on the same 
frequency without interference and this takes 
squeeky-clean packet structures with short interrupt 
loops in the TNCs. Everyone keeps adding more 
tasks for the poor TNC to try to keep up with — we 
are using a cut version in our local 220 net that is 
totally compatible (terminal to terminal) with any ver- 
sion of AX.25 but only uses a bit more than 3k of 
EPROM in a Vancouver or Ashby TNC. With C-64s 
selling for $129 and disk drives for less than $150 it 
makes sense to strip the TNC software to make it as 
transparent to ASCII as possible. 


When two stations can be running MacPaint 
graphics on each other’s machine, packet operation 
will have graduated high school... I don’t want to 
speculate on College! 


We have been running tests for several months 
on Doug Lockhart’s (VE7APU) V2 protocol and find 
parts of it to be very clean, until he gets tangled up in 
designing another monitor — just what we don’t 
need. We are stripping it down to bare-bones and find 
its throughput far exceeds AX.25 at the same link 
speed and very useful on our point-to-point 
microwave links. It only took a few minutes to 
assemble his source code and burn new EPROMS, 
make a simple wiring patch and any Vancouver or 
Ashby TNC is running V2 — try that on your "OEM 
acceptable designs”. 


We need open source code for program 
modification that can be assembled on any CP/M or 
MS-DOS machine. ASM is not very fancy, but 
everyone has access to it — which they sure do not 
have with MAC, RMAC, M80, etc. Let the people 
who hung up on UNIX,t Pascal, Forth, and C work on 
programming gateway controllers that will be totally 
transparent to us poor people! AND, used on chan- 
nels we don’t have to compete with!. 


OK, off the soapbox, but I seem to be the only 
voice from the wilderness that keeps saying manufac- 
turers that sell a few hundred units always try to 
prevent any improvement that may require them to 


+ UNIX is a trademark of Bell Laboratories. 
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modify those units already sold or admit they may be 
obsolete. If you hear of anyone that can make an 
EXAR chip set come anywhere near the performance 
of an Rixon or Telco 202 modem, please let me know. 
I’ve got a lot of customers having a hard time find 
them at reasonable prices. 


Meanwhile, keep up the good work, keep you 
net open to strange signals (they may be better). And 
publish anything that might work ------ 


Regards, 

Bill Ashby, K2TKN 

Box 332, Pluckemin, NJ 07978 
(201) 658-3087 


Reprinted from 
"The Australian Packeteer" 
Sydney Amateur Digital 
Communications Group, 
Sydney, Australia. 
Volume 1, Issue 6, December 1984 


Introduction to the NEW TNC Software Structure 


Just before Christmas, Les, VK2KYJ, was able 
to complete the remaining modifications to the vari- 
ous software modules that comprise the current TNC 
operating environment. This structure is based on a 
monitor written by Stu Beal, VE3MWM, that incor- 
porates a resident monitor/debugger, allows down- 
loading of the TNC memory to disk, and enables a 
choice of network protocols to be selected. 


The software is modularized into four seg- 
ments: 


Address 0000H consists of the monitor, ini- 
tialization routines, and utilities such as AUTO- 
BAUD. On power-up, this module reads the first 40 
bytes of each of the ROMs located on hex boundaries 
1000, 2000, 3000, and 8000 to BO00O (if pro- 
vided), and identifies each of the 2732 ROMs in the 
start-up menu. 


When one of the protocol choices is made, a 
further identification of the software version is 
printed. 

Initially, no response appears of the screen until 
the autobaud facility is invoked. This facility has 
been provided to eliminate any necessity of knowing 
the terminal (DTE) data rate, parity conditions, or 
start/ stop requirements. 

Typing ‘., .,’ acouple of times will bring up 
the start-up menu with its choices of protocols or 
monitor routines. 


This initial release has provided Vancouver V2 
and the current 1.3 protocols at addresses 1000H 
and 3000H respectively. At this time we have only 
the original AMRAD AX.25 software version 5.1. 
This module uses an unusual command structure that 
is quite different from the Vancouver format. We are 
waiting for latest version copy to arrive (5.5C) before 
a general release of this AX.25 software is made. It is 
hoped that this version will adapt easily to the X.3 ter- 
minal control commands and that the V2 TIP can be 
used for both protocols. (If anyone is desperate for 
the AX.25 version 5.1, we have a working ROM at 
address 30000H. However, this version only allows 
one level of digipeating. We prefer that everyone 
wait for 5.5C to be made available as this cuts down 
on nuisance ROM-burning. The 5.5C version com- 
pletely implements the AMRAD/ARRL AX.25 
specification which includes eight levels of digipeat- 
ing as initially proposed by TAPR.) 

A TNCDUMP routine (13k) is available for use 
with the monitor. For those of you in the Sydney 
local area, this file can be downloaded as 
TNCDUMP.ASM and requires MAC for assembly. 


With the monitor functions, everyone now has 
the capability to dissect packets to their heart’s con- 
tent. By poking around in the CCA area of your own 
TNC, a similar dump of its contents can be made to 
your screen as from the DR. 


The 16k of machine code in the new ROMs is 
sourced from over 320 kilobytes of assembly code. 
We'll have a closer look at the breakdown in the next 
newsletter. 


A question that no doubt comes to mind is 
"Why provide 1.3 when V2 has essentially super- 
ceded it?". Well, simple... until someone can get the 
various PBBSs, RCPMs, DRs, and gateways con- 
verted to V2, debugged and proven, a transition 
period will be required. (As well, there are those who 
like V1.3 for its elegant simplicity.) In addition, we 
would lose 50% of our compatibility to the growing 
TAPR TNC holders. 


For the benefit of SADCG members that don’t 
have TNCs yet or have another brand’, here are some 
examples of screen printouts under the new software 
structure: 


The following examples have been updated and show 
AX.25 as the second protocol choice instead of Van- 
couver Protocol V1.3 — Editor 

VADCG Terminal Node Controller 

SADCG Master Control Subsystem 

January 2, 1985. VK2BVD 


1) Vancouver Protocol - V2 
2) AX.25 Protocol 
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Select a Protocol from the preceeding, 
or press RETURN to enter Monitor: <CR> was entered 


TRAP REGISTERS: 

808S PC=#017D SP=4400 IM=07 A=0D F=54 BC=002E DE=3000 HL=4075 
8250 RBR=0D IER=00 IIR=01 LCR=03 LSR=00 MCR=07 MSR=33 

8273 Status-00 Result=FF RXIR=60 TXIR<-FF 


Commands are Initialise, Return, Dump, Load and Save. 
Type the first letter only. 


MON>Initialise TNC. 


VADCG Terminal Node Controller 
SADCG Master Control Subsystem 
January 2, 1965S. VK2BVD 


1) Vancouver Protocol - V2 
2) AX.25 Protocol 


Select a Protocol from the preceeding, 
or press RETURN to enter Monitor: 1 


Executing selected Protocol 


LIPTT2 010285 NIP 01028S TIPTT2 010885 


*co vk2kyj 
VK2KYJ no contact RC=00 


*monitor 


TRAP REGISTERS: 

8085S PC=29F4 SP@43FO IM=-01 A=FO F=04 BC=0002 DE=4F4D HL=29F0 
8250 RBR<OD IER=OD IIR=01 LCR=03 LSR=60 MCR=70 MSR=30 

8273 Status-00 Result=-F4 RXIR=-0A TXIR=0D 


Commands are Initialise, Return, Dump, Load and Save. 
Type the first letter only. 


MON>Save TNC memory to host computer. 


Please load and run TNCDUMP on your computer. 
Type “x" if this is not possible. 


MON>LOAD : 7020 
7020:00-53 
7021:00-41 
7022:00-44 
7023:00-43 
7024:00-47 
7025:00-20 
7026:00-20 
7027:00-20 
7028:00-74 
7029:00-65 
702A:00-73 
702B:00-74 
702C:00-20 
702D:00- 
702E:00- 
702F:00- 
7030:00-S6 
7031:00-4B 
7032:00-32 
7033:00-42 
7034:00-S6 
7035:00-44 
7036:00-20 
7037:00-20 
7038:00- 


MON>DUMP : 7000 


7000:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .........4---- 


7010:11 22 33 44 55 66 00 00 00 00 00 00 00 00 00 00. 
7020:53 41 44 43 47 20 20 20 74 65 73 74 20 00 00 00 SADCG 
7030:S6 4B 32 42 S56 44 20 20 00 00 00 00 00 00 00 00 VK2BVD 


MON>Return to interrupted program. 


*co vk2kf4j 
VK2KFJ no contact RC=-00 


*mo 

TRAP REGISTERS: 

8085S PC=29F4 SP=43F2 IM=-01 A=FO F=04 BC=-0002 DE=4F4D HL=29F0 
8250 RBR=0OD IER=“0D IIR=01 LCR=03 LSR=60 MCR=07 MSR=30 

8273 Status=-00 Result=<F4 RXIR-0A TXIR=0D 


Commands are Initialise, Return, Dump, Load and Save. 
Type the first letter only. 


MON>Initialise TNC. 
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7040:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .........----- 
7050:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 OO ............-.- 
7060:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..........---- 


VADCG Terminal Node Controller 
SADCG Master Control Subsystem 
January 2, 1985. VK2BVD 


1) Vancouver Protocol - V2 
2) AX.25 Protocol 


Select a Protocol from the preceeding, 
or press RETURN to enter Monitor: 2 


Executing selected Protocol 
LIPAX25 123184 TIPAX25 123184 


CQ DX de vk2bvd0 
CQ DX DVK2BVD02CQ DX DVK2BVD0?CQ DX DVK2BVD02?CQ DX DVK2BVD0? 


Reprinted from 
"The Australian Packeteer" 
Issue 2/No 1 
January/February 1985, page 2 


ARRL AX.25 Protocol 


Many readers with commercial TNCs may not 
be aware that the VADCG TNCs also support the 
ARRL Standard AX.25 protocol. The current issue is 
the AMRAD Version 5.1 and the latest 5S.SC Version 
will be implemented when it is received. [I took a lot 
of flak after the last newsletter as the menu display 
didn’t have the AX.25 ROMs installed at the time. In 
fact, they were loaned out to another station for HF 
experiments. So, for all the disbelievers, here is a pic- 
ture of the current menu: ] < Ed: See Above > 


We have yet to receive the current upgraded 
AMRAD AX.25 software. It looks great! and 
Howard WDSDBC has pointed out the following new 
features: 


e help menus 


* programmable baud rates for both the packet 
channel and the terminal control 


¢ machine level monitor 

¢ multi-repeater operation 

¢ host mode from the keyboard 
¢ DCDraised high on connect 


‘*e monitor mode disable from the keyboard 


* clear screen command 
¢ variable transmit relay delay times 
¢ alter user call sign 


In addition, the following bugs were fixed in 
5.5C: 


* made host mode transparent to data 
¢ large frame receive problem 

¢ allow self-connects 

¢ changed LF insertion to AX.28 


the ‘packet’, Issue 10, September 1985 


VE7PKT REPEATER 
SOFTWARE CHANGED 


On Thursday, July 25/85, the VE7PKT repeater 

/ beacon TNC was modified for 2732 EPROMs and a 
new repeater software package installed. RPT20 is an 
adaptation by Les Grant/VK2KYJ of John 
Vandenberg/VE3DVV’s RPT13 package (see Issue 8 
of the PACKET) to V-2 on the VADCG TNC. 
Summary: 
e All users are repeated unless they LOGOFF 
¢ Time Of Day clock added 
e 2 Levels of commands are supported: 

— Level 1 (public, any V-2 station) 

— Level 2 (operator commands) 
¢ Repeater failure detection and error handler. 


(software detected failures are saved and 
recovered if possible) 


¢ Error logging (software detected failures are 
counted, and time and day of last failure is saved) 


* Software hooks in RAM added to allow down- 
loaded code to be added for further development 
(note that downloader is not part of this package) 


e Acalendar has been added 
Level 1 (public) Commands: 
TIME 
display current time and message 
LOG 
shows users log status 
LOGON 
logs user onto repeater 
LOGOFF 
logs user off repeater hs 
STATUS : 
display repeater status, repeater enabled / dis- 
abled, failure log,... 
CLEAR : 
clear CCA and Tx/Rx buffers 
SAVE : 
save CCA and Tx/Rx buffers for 
DUMP : 
dump CCA and Tx/Rx buffers in 256 byte 
blocks, to user 
Level 2 (control) Commands: 
RESET : 
reset the repeater 


TIME :HHMMSS 
set time of day (TOD) clock 


DAY :XXX 
set Julian date 
DATE :MMM DD, YY 
set current date (calculates Julian date) 
MSG :<TEXT...> 
change 5 minute broadcast message (255 char- 
acters maximum) 
REPEATER :ON 
enables repeat function 
REPEATER :OFF 
disables repeat function 


IDENT :ON 
enable 5 minute broadcast ident. 
IDENT :OFF 


disables identification, UNLESS there has been 
receiver activity in the last 5 minutes 


DUMP :XXXX 
dump any memory area (256 byte blocks start- 
ing at XXXX hex) 


TABLE : 
clear user logon table to FFFF, ALL users are 
logged on 


VADCG BBS ON THE AIR 


The VADCG acquired a NEC PC-8801A 
microcomputer system at a distributors clearance sale 
in May/85 and in June/85 started testing as a packet 
radio bulletin board system at the QTH of Al, 
VE7DPM. The 8801A is a Z80A 64-KBytes CP/M 
2.2 system with 2 x 8 inch DSDD drives (2.4- 
MBytes) 

Software used is an adaptation of the public 
domain BYE program for remote CP/M systems, with 
a bulletin board system (RBBS in BDS-C) for a 
front-end. It provides typical landline BBS services as 
well as remote CP/M access allowing running of pro- 
grams and upload/download of files, when a suitable 
file transfer protocol is chosen for packet radio. 


There is discussion of putting the system on a 
telephone modem to allow access to non-hams and 
hams who are not on packet yet. There would be a 
black box built that would connect to the BBS, 
depending on which service "rang up" the system 
first. 

Hours of operation are intermittent at the 
present time, but it is available most evening hours 
and on weekends, when VE7DPM is not using his 
TNC for other activity. To access the BBS, COnnect 
VE7DPM using V-2 on 145.65-mHz. If you aren’t 
already registered, please enter your first name and 
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hamcall on one line, when asked for your name. You 
will be asked for a password, which you should enter 
to prevent hackers who may be dialing in the yet-to- 
be-installed dial-up access, from using your name. 


An article describing the implementation of this 
RCP/M system and BBS software will appear in the 
next issue. 


X.3/X.28 RECOMMENDATION 


In the last issue of "the packet" it was reported 
that Doug Lockhart, VE7APU made a recommenda- 
tion to the ARRL Ad Hoc Digital Committee that the 
CCITT recommendations X.3 and X.28 be adopted as 
a standard for asynchronous terminal communication. 
The recommendation was accepted unanimously and 
VE7APU was asked to prepare a specification docu- 
ment for these protocols as applied to the Amateur 
Radio environment. VE7APU prepared a paper 
which was presented at the Fourth ARRL Computer 
Networking Conference in San Francisco. This paper 
was very well received with no negative comments. 


However, before the Committee can make any 
recommendations to the ARRL Board of Directors, a 
more formal specification document, formatted in a 
different style must be prepared. This is being done 
at the present time. 


Note that in making this recommendation, it 
was not VE7APU’s intent that other developers 
exclusively use this interface or that other presenta- 
tion level protocols be excluded from endorsement by 
the ARRL board of directors. Other and different 
presentation level protocols are needed as well. It 
was presented because it seems to be able to solve or 
alleviate some problems which many current asyn- 
chronous terminal interfaces still have. It is also not 
the intent to freeze the development of presentation 
level protocols for asynchronous terminals. We 
should be free to make changes and improvements as 
they appear. This proposed protocol is not the perfect 
asynchronous terminal interface. 


VE7APU’s paper is included in this newsletter 
for your information. The X.3/X.28 protocols were 
programmed into the V-2 implementation for the 
VADCG TNC in the summer of 1984 and have pro- 
ven to be very useful. At this time it is not known 
whether they have been implemented in any other 
TNC software but I believe other software developers 
are doing this at the present time. 


The use of these protocols would have a 
number of advantages over the protocols previously 
used to control asynchronous ASCII terminals con- 


nected to TNCs: 


1. | Use of a published worldwide standard already 
in use by several hundred thousand people 
daily. 

2. A reduced number of commands required to 
learn by users and program by software 
developers. This would also be helpful to non- 
English speaking users. 


3. New functions added later will likely not 
require new commands and responses but only 
the use of new parameter numbers. 


4. __ A Standardized interface for application pro- 
gram developers using the asynchronous termi- 
nal interface. (Note that other presentation 
level protocols should be developed for the 
interfacing of host computers to TNCs) 


5. Amn architecture (X.3) which enables develop- 
ment of session level protocols. (such as X.29) 
Previous presentation level protocols used in 
Amateur TNCs made it extremely difficult or 
impossible to develop any session level proto- 
cols and no work has been done in this area so 
far. 


X.3 AND X.28 PROTOCOLS FOR 
TERMINAL NODE CONTROLLERS 


Douglas Lockhart, VE7APU 


9531 Odlin Road 
Richmond, B.C. V6X 1E1 
(604) 278-5601 


Abstract 


This paper proposes the adoption of an 
extended version of CCITT recommendations X.3 
and X.28 for use in Amateur radio Terminal Node 
Controllers. The various X.3 parameters and X.28 
commands and service signals (messages) are out- 
lined and the extensions in place in the V-2 software 
implementation on the VADCG (Vancouver Amateur 
Digital Communication Group) TNC are discussed. 


Terminology 

This paper is semi-tutorial in nature and is 
intended for Amateur packet radio operators. Some 
of the terms used in the official X.28 protocol docu- 
ment have been translated into terms that hopefully 
may be more familiar to the readers. For example, the 
word “TNC’ is used instead of ‘PAD’ and the word 
‘terminal’ is used instead of ‘DTE’ and in actual 
usage may be a microcomputer running host pro- 
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grams or a terminal emulation program. The terms I 
am using come from a variety of disciplines. My apo- 
logies if this makes it more difficult to understand 
rather than less so. 


The Problem 


In 1979, the VADCG TNC was the only one 
available and the software I had written for it only 
allowed two commands — control-Y caused a discon- 
nect and a call sign followed by control-X caused a 
connection to be made. The very limited number of 
commands and the availability of only one version of 
software made it very easy for the new user to learn to 
use even though it was not very flexible. 


The situation at the beginning of 1985 is quite 
different. There are now about 6 different TNCs 
available and three different protocols available, most 
with several different flavours or versions. Each com- 
bination of TNC and software has its own unique set 
of user commands. The more recent versions have a 
large and very flexible set of commands. In order to 
use the TNC efficiently, the user must learn his 
TNC’s commands. With 40 or more commands fre- 
quently available, this becomes time-consuming. 
Furthermore, when the user tries to use the same com- 
mands on a different TNC or on the same TNC using 
a different link-level protocol, the commands are 
likely not to work and another set of commands must 
be learned. This learning process may be slowed by 
lack of advice from users with different command 
sets. 


But perhaps the most serious problem that the 
lack of standardization of the command set causes is 
that application programs written for host computers 
will not be transportable. A special version for each 
case will have to be written. This situation has the 
potential of getting worse as new levels of protocols 
are developed, new TNCs become available and as 
new programmers begin to write software for TNCs. 


The Solution 


The commercial world ran into these same 
problems in interfacing ASCII terminals to the Packet 
Switched Public Data Networks (PSPDN) and 
developed a set of standards to solve their problems. 
The CCITT adopted Recommendations X.3 and X.28 
in 1977. Recommendation X.28 defines the com- 
mands the terminal user sends to the PAD (Packet 
AssemblerDisassembler) and the service signals 
(messages) sent from the PAD to the terminal user. 
The PAD performs a similar function to the TNC 
(Terminal Node Controller) in the Amateur environ- 
ment. Recommendation X.3 defines a set of parame- 


ters in the TNC which tailor its control of the termi- 
nal. In the ISO protocol model, X.3 and X.28 are a 
Level 6 or Presentation level protocol. To quote the 
OSI draft, "The purpose of the Presentation layer is to 
represent information to communicating application- 
entities in a way that preserves meaning while resolv- 
ing syntax differences." 


In August 1984 I received information on the 
CCITT X.3, X.28 protocols and realized that these 
standards could solve most of these problems if they 
could be implemented on all TNCs. On August 20, 
1984 I wrote to the ARRL Ad Hoc Committee on 
Amateur Radio Digital Communication proposing the 
adoption of these standards. I also began recoding the 
V-2 software I was writing to use these standards. 
The proposal received a favourable response at the 
September, 1984 Committee meeting. The imple- 
mentation described in this paper was completed in 
October, 1984. At the Committee meeting in 
November, 1984 I was asked to prepare a paper 
detailing my recommendations for a protocol based 
on the CCITT X.3 and X.28 protocols to be used in 
the Amateur packet radio environment. This is that 
paper. 

The environment that the X.3/X.28 protocols 
were intended to work in is very similar to that found 
in most Amateur packet radio stations. However 
there are some minor differences which necessitate 
some deviation from the official recommendation. 
X.3/X.28 was intended to interface ASCII terminals 
and because of this, it only expected 7-bit ASCII 
characters to be used. In the Amateur environment, it 
is sometimes useful to transmit 8-bit binary data such 
as in object code. Some modification and extension 
of these protocols has been made in this recommenda- 
tion to accommodate this type of usage. 


Additionally, the terminal user in the commer- 
cial environment had no control over the tailoring of 
the operation of the data link level software. This 
recommendation includes extensions to standardize 
some of this control the Amateur user is already fami- 
liar with. While an attempt has been made to keep the 
X.28 commands and messages as similar to the 
official recommendation as possible, several have had 
to be changed to be more meaningful in the Amateur 
packet radio environment. These changes are similar 
to the type of changes made by commercial users 
when adapting these protocols to their own environ- 
ments. 


Recommendation X.28 


The first problem encountered in establishing 
communication between the terminal and TNC is to 
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initialize the TNC to the proper data rate and data for- 
mat of the terminal. A sequence of characters are sent 
by the terminal to the TNC until the TNC recognizes 
the speed and format of the terminal and responds 
with an initial message. This function is commonly 
known as ‘AutoBaud’ or ‘Autospeed’ or “Adaptive 
speed’. Unfortunately X.28 does not define any char- 
acter sequence for implementing this function and in 
practice there are several different methods employed 
in the data communications industry. The current V-2 
implementation on the VADCG TNC uses alternating 
‘” and ‘,’ (period and comma) for detection of Baud 
rate and format. This system is superior to single 
character AutoBaud implementations because it can 
detect the type of parity and number of data bits used 
in addition to the Baud rate. In some applications it 
may be desirable to have the TNC always come up at 
a fixed Baud rate and data format and in this case the 
autoBaud function may be unnecessary. 


After communication has been established 
between the terminal and TNC, both data for the link 
and X.28 commands for the TNC may be sent by the 
terminal user to the TNC. Likewise, messages gen- 
erated by the TNC and data from the link can now be 
passed to the terminal at this time. Since both data 
and commands are being multiplexed over the 
TNC/terminal connection, the question arises as to 
how to differentiate the two types of data. The TNC 
can operate in two modes: while in ‘command mode’ 
characters received from the terminal are interpreted 
as commands and while in ‘data transfer’ mode the 
characters are interpreted as data intended to be 
passed on the link. The TNC will go from data 
transfer mode to command mode when it receives the 
X.3 command escape character defined by X.3 param- 
eter #1. This command escape character may be set 
to any value by issuing an X.28 command to modify 
the setting of an X.3 parameter. 


The problem of transmitting the command 
escape character as data is solved by transmitting two 
escape characters in succession from the terminal. 
This sequence is recognized by the TNC and causes 
the TNC to pass a single escape character to the link. 
By using this ‘byte stuffing’ technique it is possible to 
transmit any combination of characters as data to the 
link. This technique is convenient for terminal users 
and for file transfer of ASCII files but it is not full 
data transparency. For transmission of binary files by 
host computers whose file transfer program cannot 
handle this ‘byte stuffing’ technique, another system 
must be used. X.3 parameters may be set so that the 
TNC does not recognize any characters as having spe- 
cial meaning — including the command escape char- 
acter. (See X.3 parameters 1, 12, 13 and 15) Now we 


have full data transparency. 


But we have a new problem. After we have 
transferred our transparent data, how do we get back 
into command mode? We can’t use a command 
escape character to do it so it has to be done another 
way. The setting of X.3 parameter 7 to a value of 8 
causes the TNC to go into command mode when a 
break signal is generated by the terminal. Some ter- 
minals and computers are not capable of generating a 
break signal but can get back into command mode by 
resetting the TNC causing it to return to the initial 
default values of the X.3 parameters. 


Resetting of the TNC seems like an extreme 
measure and other alternatives for users incapable of 
generating a break signal should be found. This is an 
area where the standard may need to be extended to 
meet the special needs of the Amateur Radio environ- 
ment. My suggestion is to use a special sequence of a 
number of characters followed by sufficient time to 
cause the idle timer to expire. (See X.3 parameter 4) 
At expiry of the timer, the TNC could check the 
preceding characters and enter the command mode if 
a match is found. This method should be virtually 
foolproof because a computer would never allow this 
much wait time while sending a transparent file. This 
is an area of further study. 


X.28 Commands 


X.28 commands are not case-sensitive. They 
can be typed in either upper or lower case or mixed 
case with the same results. Commands are terminated 
by carriage return <cr> or by ‘+’. Officially, X.28 has 
defined the following 8 commands: 

SET <parameter list> 
To change X.3 parameter values 
PAR? <parameter list> 
To display the current value of specified X.3 
parameters. 
SET? <parameter list> 
Sets and then displays the current value of 
specified X.3 parameter values 
PROF <identifier> 
To set the X.3 parameters to a standard set of 
values 
STAT Request status of TNC 
CLR To terminate a link connection 
RESET To reset a link connection 
INT __ To transmit an interrupt packet 
This is a fairly short list of commands. This is 


because the function of most of the TNC commands 
we are familiar with is done by modification of the 
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X.3 parameters. 


There are a number of problems with using this 
command set in the Amateur packet radio environ- 
ment which I will discuss in the following paragraphs. 


X.28 does not define a command used to estab- 
lish a connection because the format of such com- 
mands is very environment-specific. In the V-2 
implementation the following command is used to 
establish a link-level connection: 


CONNECT <call-sign><cr> 


The call-sign is entered as an ASCII field in either 
upper or lower case. It is converted to upper-case and 
padded on the right with ASCII blanks. In the V-2 
implementation this field is 7 characters long with the 
7th character identifying an extension to the call sign. 
In implementations for other protocols, this field may 
be only 6 characters long. Additional information 
may need to be specified when establishing a connec- 
tion when digipeating is used and when network level 
protocols are developed for Amateur packet radio. 
This information may optionally follow the call sign 
in the ‘CONNECT’ command but this is a subject for 
future consideration for incorporation into a standard. 
With a network level it may be desirable to use the 
“CONNECT’ command to establish a network level 


connection and use ‘LINK’ to establish a link level . 


connection independently. 


The X.28 ‘CLR’ (clear) command is used to 
terminate a connection. Unfortunately, this command 
does not correspond to current Amateur packet radio 
conventions where the ‘DISCONNECT’ command is 
usually used. I propose we use the ‘DISCONNECT’ 
command for this purpose. When network level pro- 
tocols are developed, the ‘DISCONNECT’ command 
can be used to terminate a network level connection 
and the ‘UNLINK’ command can be used to ter- 
minate a link level connection. 


The X.28 ‘INT’ command has no counterpart in 
the Amateur packet radio environment at the present 
time. There is no such thing as an ‘interrupt packet’ 
in current link level protocols. When higher level 
protocols are implemented, there may be a need for 
this command. This is a subject for future considera- 
tion. 

The ‘SET’ command should be implemented 
exactly as described in the X.28 recommendation. As 
an example, to set X.3 parameter 5 to 3 and parameter 
21 to 128 type the following: 


SET 5:3 21:128<cr> 


The parameter numbers and values are entered as 
pairs of decimal numbers. Any blank or non-numeric 


character can be used as a separator between the 
numbers. The above could be entered as follows: 


set 5 3 21 128<cr> 


The X.28 ‘PAR?’ command parameters is a list 
of X.3 parameter numbers whose values are to be 
displayed. The parameter numbers are entered in 
decimal. 

The X.28 ‘SET?’ parameters are the same as 
for the ‘SET’ command above. The function of the 
‘SET?’ command is basically similar to that of the 
‘SET’ command followed by the ‘PAR?’ command 
and because of this redundancy it has not been sup- 
ported in the current V-2 implementation. However, 
since it may be more convenient, this command 
should be considered optional. 


The X.28 ‘PROF’ command sets the X.3 
parameters to a particular set of values or ‘profile’. 
The identifier in the command is a decimal number 
which identifies the particular profile desired. X.28 
defines two profiles — simple and transparent but 
many networks offer other profiles tailored to the 
characteristics of a particular terminal or application. _ 


The transparent profile is used when the TNC 
needs to be “invisible” to the user. Commands can 
not be used, no messages are generated by the TNC 
and editing and echo are not supported. 


The simple profile supports commands and uses 
a set of X.3 function which require a minimum of ter- 
minal features. Messages are generated by the TNC 
and echo and flow control are enabled. Data is for- 
warded whenever a control character is received by 
the TNC. 


The ‘initial profile’ is the set of X.3 parameters 
that are in effect when the TNC is initialized or 
powered up. It is usually similar to the simple profile. 
TNCs that support non-volatile RAM (NOVRAM) 
can have the ability to tailor their initial profile while 
others can only support a fixed initial profile bummed 
into EPROM. The ‘PROF’ command is particularly 
useful in the latter case because it can usually reduce 
the amount of time required to tailor the X.3 parame- 
ters after powering on the TNC. It can also be useful 
when the TNC is sometimes switched to a different 
function where substantially different characteristics 
are required. This paper recommends that the 
‘PROF’ command should be considered optional but 
desirable. It is not supported in the current implemen- 
tation of V-2 but will be implemented in a future 
release. 


The ‘STAT’ command takes no parameters but 
causes the TNC to display the current connect status 
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of the TNC. This command is not presently imple- 
mented on V-2 since the connect status of the TNC is 
indicated by two other methods. However, this com- 
mand should be implemented since TNC software 
capable of multiple links and connections will become 
available and the connection status of a TNC may be 
difficult to determine without this command. 


The ‘RESET’ command currently is not sup- 
ported because the current link level protocols do not 
support a reset packet. This command should be 
implemented when new protocols are developed 
which support this function. 


You will note the very small number of com- 
mands needed by X.28 to control a TNC. Most func- 
tions are performed by the setting of X.3 parameters 
using the ‘SET’ command. The reduction in the 
number of messages and commands can reduce the 
learning period for a non-English speaking user and 
possibly reduce the time for programmers to recode 
the software for use with a different language. 


In general, functions which control an on/off 
type of condition or control a value that can be 
specified in a single byte can be controlled by X.3 
parameters. For example, the TNC either echoes the 
characters from the terminal or it doesn’t. Another 
example is the setting of the number of retries 
attempted on the link. 


On the other hand, functions which cause 
immediate action or require the entry of multiple 
characters are unsuitable for incorporation into X.3 
parameters and so require specific commands. An 
example of this is the ‘CONNECT’ command which 
requires the provision of a call sign and causes an 
immediate change in the operation of the TNC. 


One function common to all TNC command 
sets is the ability to set the station call sign and so 
should be incorporated into a standard. I recommend 
the following command for this function: 


MYCALL <call-sign> 


This format is similar to that of the ‘CONNECT’ 
command described above. At the present time the 
V-2 implementation uses the ‘CALLSIGN’ command 
to perform this function but the ‘MYCALL’ com- 
mand mnemonic is more familiar to users of TNCs 
and so I will be changing it in future releases. 


The commands described in this section are not 
meant to be the only commands that should belong in 
a TNC. They are intended to be a set of commands 
that should be standardized in every TNC because of 
a common need for these functions. If a specific 
function is only used in one implementation there is 
no need for standardization. However, if a function is 
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common to more than one implementation, then there 
should be an attempt made at providing a standard 
way to control that function. No doubt, as Amateur 
packet radio develops, new commands will have to be 
incorporated into this recommendation. 


To summarize this section, this paper recom- 
mends the incorporation of the following six com- 
mands into every TNC. 


SET, PAR?, CONNECT, DISCONNECT, MYCALL, 
STAT. The PROF and SET? commands are optional. 


X.28 Messages 


X.28 messages are frequently called service 
signals. The public packet-switched networks do not 
usually implement the official X.28 message set pre- 
cisely as it is defined. This is because the messages 
are not human engineered and in many cases may not 
be suitable for a specific environment. This is also the 
case in the Amateur Radio environment. However a 
number of the messages can be used. The following 
list is a subset of the official X.28 message set that I 
am recommending be used exactly as defined. 


Linefeed 
Acknowledgment of a command. 


* Command mode prompt signal. 


xxx Indicates that the line delete function is com- 
pleted. 


ERROR 
Command error. 


PAR <m:n> 
Response to SET and SET? commands. The n's 
indicate the parameter number and value in 
decimal respectively. 


PAR <1: INV> 
Response to an invalid parameter setting in a 
SET or SET? command. n is the parameter 
number. 


The following list contains messages which are 
not exactly as defined by the official X.28 recommen- 
dation but which I recommend be used in the Ama- 
teur packet radio environment. 


LINKED <call-sign> 
Indicates that a data link connection has just 
become established or a response to the 
STAT command when a data link connection 
is established. 


UNLINKED 
Response to the STAT command when a 
data link connection is not established. 
LINKING <call-sign> 
Response to the STAT command when a 
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data link connection is being attempted. 


UNLINKING <call-sign> 
Response to the STAT command when a 
data link connection is being broken. 


UNLINKED <call-sign> <reason> 
Indication that a data-link connection has 
been broken or could not be established. The 
reason is given after the call-sign and can be 
one of the following: 


BUSY The indicated station is busy. 


REM The remote data link partner terminated the 
link. 


REMERR 
The remote station detected a protocol error. 


NORM Local DISCONNECT command. 


NORESP 
The station did not respond. 


PROT Protocol mismatch. 
ERROR Terminated by link protocol error. 


TIMOUT 
Excessive timeouts on link. 


INV Requested facility not supported. 


Some of the reasons refer to facilities not sup- 
ported in all link-level protocols. In this case, these 
reasons need not be used. However, when these facil- 
ities are available, they should be implemented as 
shown. Other reasons for link termination will be the 
subject of future standardization attempts. 


It should be noted that the words, "link, linked, 
unlinked, etc." are used instead of the words, "con- 
nect, connected, disconnected, etc.” even though the 
latter terms are in more common use at the present 
time. This was done to avoid future confusion 
because of terminology. In the ISO model, "connec- 
tions” may be established at all levels. There are link 
level connections, network level connections, tran- 
sport level connections, session level connections, etc. 
In the future, TNCs will likely have software to sup- 
port multiple protocol levels, not just the link level as 
at present. TNCs capable of supporting multiple net- 
work level connections and multiple link level con- 
nections simultaneously will likely appear. When this 
happens, the term "connection" used without 
qualifiers will be ambiguous and cause some confu- 
sion. The term, "link" refers only to the data link 
layer and its use should reduce this potential problem. 
I believe that the term, "connection" without qualifiers 
should only be used to refer to a network level con- 
nection. 
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X.28 does not define the initialization message 
which appears when the TNC is initialized and I am 
making no recommendation in this area. 


Recommendation X.3 


In 1984, the official X.3 recommendation 
defined 22 parameters used to tailor the way the TNC 
controls the interface between the TNC and terminal 
or host computer. Unlike the X.28 recommendation 
which needed substantial modification to adapt it to 
the Amateur packet radio environment, these X.3 
parameters can be implemented almost exactly as 
described in the official recommendation. For the 
Amateur packet radio environment, this paper recom- 
mends some extensions to this set to provide addi- 
tional tailoring of the terminal interface, tailoring of 
the operation of the link interface and to control 
operation of the network level if implemented. 


In October of 1984, the V-2 implementation on 
the VADCG TNC supported an additional 14 parame- 
ters beyond the 22 used by the official recommenda- 
tion to provide this additional control. The parame- 
ters supported in this implementation are summarized 
in Table 1. The official X.3 parameter values which 
are not supported are indicated and extensions to the 
standard are also indicated. All parameters beyond 22 
are extensions. The default values in the distributed 
software are also indicated. These defaults should not 
be considered as part of this recommendation but they 
do serve as an example of an ‘initial standard profile’. 


In this implementation the X.3 parameters have 
been set up as a contiguous string of bytes in memory. 
The first byte being the value of parameter 1 and it is 
recommended that the parameters be implemented in 
this way. Each byte has a set of legal values defined 
by this recommendation. The software should not 
allow non-legal values to be set into these parameters. 


Parameter 1 defines the character sent to switch 
the TNC from data transfer mode into command 
mode. While the official standard only permitted 
values of 0 and 32-126 to be specified, I have 
extended this range to allow all 8-bit byte values. 
This was done because TNCs are frequently used with 
host computers rather than ASCII terminals and so are 
capable of transmitting 8-bit characters. A value of 0 
set in parameter 1 prevents escape from data transfer 
mode by the transmission of a command escape char- 
acter. Only one command can be issued from the ter- 
minal per escape. The TNC reverts back to command 
mode after each command is issued. Reception of the 
escape character also caused any accumulated data 
received from the terminal to be forwarded as a 
packet. 
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Parameter 2 controls whether the TNC will 
echo characters received from the terminal. 


Parameter 3 defines characters which the TNC 
recognizes as a signal to forward any accumulated 
data received from the terminal and transmit it as a 
packet on the link. See parameters 1, 4 and 33 for 
other conditions which cause accumulated data to be 
forwarded. Note that values in parameter 3 can be 
added together to get some forwarding combinations 
that are not standard in the official recommendation. 
For example, a value of 10 can be specified to cause 
forwarding on carriage return (CR), DEL, CAN and 
DCZ2. 


Parameter 4 defines a time interval of terminal 
inactivity which is used to forward any accumulated 
data as a packet. The timer is started each time a 
character is received by the TNC. If it expires, the 
data is forwarded. This forwarding method is dis- 
abled if the parameter is set to 0. 


Parameter 5 defines the type of flow control 
indication is to be used by the TNC to regulate the 
flow of data from the terminal. In addition to the X- 
ON/X-OFF flow control method defined in the official 
X.3 recommendation, the TNC can also control the 
RTS (Request to Send) line on the terminal interface 
to indicate whether it is ready to accept data or not. 
An active RTS line indicates that the TNC is ready to 
accept data. This extension was necessary to support 
the transfer of non-ASCII data (such as object code) 
by host computers to the TNC while still retaining 
flow control capability. The X-ON/X-OFF protocol is 
not capable of doing this. 


Parameter 6 controls the use of X.28 messages 
by the TNC. These messages can be disabled as is 
frequently necessary when the TNC is connected to a 
host computer rather than a terminal or when the TNC 
is to remain transparent to the user. The network 
dependent format service signals are not supported 
because this requires a protocol layer that is not used 
in Amateur TNCs at the present time. It is a subject 
of future consideration when the protocols are in 
place that can support this function. 


Parameter 7 determines the action of the TNC 
when it receives a break signal from the terminal. 
The only values that are supported by the V-2 imple- 
mentation are 0 and 8. Value 8 provides another way 
to escape to command mode for terminals which sup- 
port the break signal. It may be particularly useful for 
host computers wishing to switch from a transparent 
mode of operation after transferring a file. Values 
1,2,4,5, and 21 are not supported because there are no 
interrupt packets, reset packets or any way to indicate 
the detection of a break in a packet using the current 
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Amateur link level protocols. Their use should be 
reconsidered when higher level protocols which sup- 
port these functions become available. Although not 
implemented at present, value 16 which supports the 
ability to flush TNC data for the terminal is useful. 


Parameter 8 can be set so that the TNC will dis- 
card all data for the terminal. The only use for this 
feature at the present time is for testing purposes. 
When session level protocols are implemented in 
Amateur packet networks, this feature will become 
useful. It is easy to implement. 


Parameter 9 controls the number of padding 
characters (ASCII nulls) which are sent to the termi- 
nal after every carriage return character. This is fre- 
quently required by hard copy terminals which 
require extra time to perform a carriage return. Some 
video terminals and terminal emulation programs 
require extra time as well. In the V-2 implementation 
the padding characters are actually sent but this func- 
tion may be implemented by adding the equivalent 
amount of time fill as well. The official X.3 recom- 
mendation only allowed up to 7 padding characters 
but the V-2 implementation allows up to 255 padding 
characters or equivalent time fill. 


Parameter 10 controls the point where long 
lines are broken or folded so that they display as mul- 
tiple lines. This has its main use with RTTY termi- 
nals to prevent the last characters in a long line from 
Overprinting at the end of the line. Some video termi- 
nals do not support line folding and may need to use 
this feature. 


Parameter 11 indicates the speed of the termi- 
nal. Take special note that this parameter cannot be 
changed by the X.28 SET or SET? commands. It is a 
read only parameter that is set by the TNC initializa- 
tion process or by the AutoBaud routine. Its only use 
at present is to determine what speed the terminal is 
running at if this is not known. It will have other uses 
when session level protocols are used in Amateur 
packet networks. The values indicated as not being 
supported are Baud rates that the V-2 AutoBaud rou- 
tine does not support. Baud rates not in the list which 
are implemented should use values above 18 and will 
be the subject of future standardization efforts. 


Parameter 12 defines the type of flow control 
signals which the TNC will act upon to control the 
flow of data from the TNC to the terminal. The func- 
tions provided by this parameter have been extended 
beyond the official recommendation in order to be 
able to pass binary data to the terminal or host com- 
puter. An additional flow control method using the 
CTS (Clear to send) line from the terminal has been 
provided. If value 2 is set, the TNC will only send 
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data to the terminal when the CTS line is active. Note 
that X-ON/X-OFF flow control cannot be used while 
transferring binary data. When X-ON/X-OFF flow 
control is specified here, the X-ON and X-OFF (DC1 
and DC3) characters are not forwarded. 


Parameter 13 controls the insertion of line feeds 
by the TNC after carriage returns either going to or 
coming from the terminal and after carriage returns 
being echoed back to the terminal. Any combination 
of these insertions may be selected. 


Parameter 14 controls the number of padding 
characters (ASCII nulls) to be inserted after every line 
feed being sent to the terminal. This feature is used 
with terminals which take a long time to do a line feed 
operation. This is somewhat similar to parameter 9 
and equivalent time fill can be used instead of sending 
padding characters. 


Parameter 15 controls whether editing opera- 
tions can be performed on data accumulated by the 
TNC in data transfer mode but which have not been 
forwarded yet. Editing is always available in com- 
mand mode. The characters acted upon for the edit- 
ing functions are defined in parameters 16, 17 and 18. 
Editing is normally used with terminals rather than 
host computers. The V-2 implementation does not 
turn off idle time forwarding automatically when edit- 
ing is specified as per the official X-3 recommenda- 
tion. Care should be taken with the specification of 
parameter 3 to ensure that data is not forwarded 
before there is a chance to edit it. 


Parameter 16 defines the editing character the 
TNC acts upon to delete the previous entered charac- 
ter from the unforwarded accumulated data. The V-2 
implementation uses the range 0-255 rather than 0- 
127 which is the official X.3 recommendation. 


Parameter 17 defines the editing character the 
TNC acts upon to delete the unforwarded accumu- 
lated data. The V-2 implementation uses the range 
0-255 rather than 0-127 which is the official X.3 
recommendation. 


Parameter 18 defines the editing character the 
TNC acts upon to redisplay the unforwarded accumu- 
lated data. This is mainly used to redisplay edited 
lines on printing terminals which do not have the abil- 
ity to erase characters. The V-2 implementation uses 
the range 0-255 rather than O- 127. 


Parameter 19 selects the type of signals that 
will be returned to the terminal when handling editing 
characters. The V-2 implementation allows for tailor- 
ing these signals for either printing or video display 
terminals. For example: for the delete previous char- 
acter operation the TNC will return the character "/" 
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for a printing terminal or the character sequence 
"<backspace>, <space>, <backspace>" for a video 
display terminal. 

Parameter 20 is used to specify which charac- 
ters will not be echoed to the terminal when echo is 
enabled by parameter 2. Note that the flow control 
characters X-OFF and X-ON are never echoed. Note 
that the values in this parameter can be added together 
to get character sets which are not in the official 
recommendation. For example, a value of 6 may be 
specified which prevents echo of LF, VT, HT and FF. 


Parameter 21 specifies whether the TNC will 
generate the parity bit in the data sent to the terminal 
and whether parity will be checked on data from the 
terminal. This parameter is not used in the V-2 imple- 
mentation. The AutoBaud routine in V-2 generates a 
like parity to that supplied by the terminal but no 
action is taken on parity errors in data received from 
the terminal. The official X.3 specification seems to 
be vague as to what action is to be taken on parity 
errors or what type of parity (even, odd, mark, space, 
etc.) will be set by this parameter. However, I recom- 
mend implementation of this parameter when its func- 
tion is clear and useful. 


Parameter 22 specifies the number of line feed 
characters that the TNC will send to the terminal 
before stopping the sending of additional characters. 
The sending will recommence when an X-ON charac- 
ter is received from the terminal. This function 
allows the terminal user to read all the information 
before it is scrolled off the screen. The X.28 message 
"PAGE" is sent to the terminal to indicate the reason 
the data transfer to the terminal has been stopped. 


Parameter 23 defines the number of additional 
characters that the TNC can receive from the terminal 
when the flow control method specified by parameter 
5 acts to stop data from coming in from the terminal. 
This parameter and all remaining parameters 
described here are extensions to the official X.3 
recommendation. This parameter was added to sup- 
port a number of host microcomputers which do not 
act immediately on flow control signals. Some micro- 
computers only check flow control signals after the 
transmission of each line which could result in lost 
data if extra buffering capability was not available at 
the time the TNC acted to suspend the data flow. 

Parameters 24, 25, 26, 27, 28 and 29 are exten- 
sions to allow for tailoring of the operation of the data 
link on the TNC. 

Parameter 24 defines the number of consecutive 
link timeouts (no response) that will be tolerated 


before "giving up". This value is used only when a 
‘CONNECT’ or ‘DISCONNECT’ command is in pro- 
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gress. When a link is established, the value in param- 
eter 25 is used. 


Parameter 25 defines the maximum number of 
consecutive link timeouts that will be tolerated on a 
data-link connection before "giving up". This value is 
only used when the link is established. See parameter 
24 for the value used when the link is being esta- 
blished or terminated. 


Parameter 26 defines the amount of time the 
TNC will wait for a response from a data link partner. 
If this time expires before receiving the expected 
response the TNC takes remedial action which is usu- 
ally a transmission polling the partner for another 
response. The V-2 implementation on the VADCG 
TNC suspends this timer when the link is busy (a sig- 
nal is detected on the channel) so that timeouts are not 
caused by use of the communications channel by 
other stations. 


Parameter 27 allows for improved usage of the 
TNC in situations where it is not possible to reliably 
determine whether the link channel is occupied or not. 
This is frequently the case with noisy links such as are 
encountered with satellite and HF channels. When a 


value of 1 is specified, the TNC ignores the status of | 


the carrier detect line and always assumes that the 
channel is clear. 


Parameter 28 defines the amount of time the 
RTS line will be active before the data is transmitted 
on the data lines. This is used to support transmitters 
and modems which are slow in turning on. This time 
delay is also used to allow sufficient time for 
receivers to unsquelch so that the first part of the data 
frame is received without error. Note that the data 
will not be transmitted until the CTS line is active too. 


Parameter 29 can be used to prevent links by 
other stations from being established. When the value 
is set to 1, the V-2 protocol responds to attempts to 
establish a data-link connection by indicating a ‘busy’ 
condition. 


Parameter 30 is intended for future link control 
functions. 


Parameter 31 controls whether the TNC will 
use the AutoBaud feature when re-initialized or use 
preset values for speed and format of the terminal 
interface. In TNCs which do not support non-volatile 
RAM, the value set by the terminal user will only be 
effective until the TNC is powered off. 


Parameter 32 controls which packets received 
by the TNC will be passed to the terminal. If set to 0, 
the TNC acts as a filter which prevents data in packets 
not intended for this station from being passed to the 
terminal. Other values to provide different filtering 
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actions should be the subject of future standardization 
efforts. 


Parameter 33 specifies the maximum number of 
characters received from the terminal which can be 
accumulated before forwarding the data in a packet. 
This determines the maximum number of bytes in the 
data field of a packet. The actual maximum frame 
length transmitted must include the overhead of the 
various protocol layers in use as well as this value and 
the maximum value that can be specified may vary 
with different protocol implementations. Care should 
be taken when specifying this parameter so that 
frames which are greater than the link partner’s abil- 
ity to handle are not generated. I recommend that all 
implementations be capable of handling values of at 
least 128 characters. 


Parameters 34 through 38 are intended to be 
used to tailor the operation of the network layer. It is 
too early in the development of Amateur packet radio 
protocols to standardize network layer functions. The 
current use of parameter 34 in the V-2 implementa- 
tion is shown in Table 1 but it is not the intent of this 
paper to recommend standards in this area. 


Parameter 39 determines how the TNC controls 
the Receive Line Signal Detect (Carrier Detect) line 
on the terminal interface which is pin 8 on the stan- 
dard EIA RS-232 interface connector. If set to 0, this 
line is always active. If set to 1, this line is only 
active when a data-link connection has been esta- 
blished. This feature is useful when the TNC is con- 
nected to a host computer. 


Parameter 40 controls the masking of data bits 
in the characters being sent to and received from the 
terminal. If this value is 255, the TNC will pass 8-bit 
characters to and from the terminal. If the value is 
127, the high order bit will be masked off (set to 0). 
Any bits can be masked off. The masking values are 
easier to understand when converted to binary. 


Recommendation X.29 


Although not discussed previously, it seems 
appropriate that CCITT recommendation X.29 be 
mentioned because it is closely related to the X.3 pro- 
tocol. X.29 is a protocol which allows a remote TNC 
to both inspect and change the X.3 parameter values. 
This allows an application program to coordinate its 
operation with that of the remote terminal. For exam- 
ple, the application program could disable echo by 
altering X.3 parameter 2 while a password was being 
entered. In the ISO model, X.29 would be called a 
Level 5 or Session level protocol because it provides 
the means to coordinate the operation of the remote 
Presentation level (X.3/X.28). A number of 
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significant advantages of the X.3/X.28 protocols will 
not be realized until a Session level of some kind such 
as X.29 is implemented in Amateur packet networks 
but it is not within the scope of this paper to make 
recommendations on Session level protocols for Ama- 
teur use. 


Implementations 


The only full implementation of the X.3 and 
X.28 protocols on Amateur TNCs that I am aware of 
is with the V-2 protocol on the VADCG TNC or 
Ashby boards. The Ashby board requires a hardware 
modification for the software to work. I understand 
that Terry Fox, WB4JFI with AMRAD is working on 
implementing this protocol with AX.25 on the 
VADCG TNC with his daughter board modification. 
He has been sent a copy of this implementation. 
TAPR representatives have indicated that they will 
provide X.3/X.28 as an optional command set on the 
TAPR board at some future date. Phil Karn, KA9Q, 
who is developing packet software for the Xerox 820 
board is also interested in using these protocols. 
From discussions I have had with representatives of 
many of the Amateur packet radio organizations, I 
feel there is widespread support for the development 
of standards based on the X.3 and X.28 protocols. 


Coordination of implementation 


Some problems may arise when implementing 
these protocols in other TNCs or with other link-level 
protocols. The following paragraphs are guidelines 
for implementors. 


Not all TNCs will support all the functions 
defined in the X.3 parameters. An invalid parameter 
message should be returned when an attempt is made 
to set an unsupported value. 


Functions which can be implemented in X.3 
parameters but which are not defined in the current 
recommendation should be implemented in parame- 
ters above 40. 


When these new parameters are used in an 
implementation an attempt should be made to coordi- 
nate these parameters with other implementations so 
that the same parameter is not used for different func- 
tions or that different parameters are used for the 
same function. On request, I have volunteered to act 
as a coordinator for this effort within the ARRL Ad 
Hoc Committee on Amateur Radio Digital Communi- 
cation. The Committee will use its facilities to act as 
a clearing house for information on X.3/X.28 imple- 
mentations for individuals who are planning exten- 
sions to these recommendations. Implementors 
should write to the Committee or directly to me at the 
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address at the beginning of this paper. 

Many functions are not suitable for control by 
X.3 parameters and will require extensions of the 
X.28 command and message set. An attempt to coor- 
dinate these extensions should be made. Implemen- 
tors should communicate details of these extensions to 
me or the Committee as described in the previous 


paragraph. 


Summary 


The protocol described in this paper has been 
tested by many Amateurs in a number of countries 
with good results and it is estimated that several hun- 
dred thousand users of public data networks use the 
X.3 and X.28 protocols daily. The temporary disrup- 
tion caused during the conversion from the old com- 
mand set to the X.3/X.28 protocols is only a small 
inconvenience when compared to the advantages of 
having a standard set of commands and messages for 
all TNCs. This inconvenience becomes even less 
significant when one considers the potential advan- 
tages of the X.3 parameters when session level proto- 
cols such as X.29 are developed for Amateur packet 
networks. 


The initial recommendations made here will 
likely be fine-tuned as a result of future discussions, 
feedback and coordination efforts but the author 
hopes that this paper will lead to the development of a 
widespread standard set of commands and responses 
for terminal users of Amateur packet radio equipment 
and to give programmers a standard interface to TNCs 
so that they may write applications that will work on 
all Amateur TNCs. The recommendations made in 
this paper do not restrict the commands and messages 
used by TNCs but do propose standard ways of con- 
trolling certain common functions. No doubt, as 
Amateur packet radio networks mature, other func- 
tions will need to be standardized and other presenta- 
tion level protocols will be developed for special 
environments. 


Reference 

[1] Shanahan, Teresa A., "Packet 
Assembly/Disassembly (PAD) CCITT Recommenda- 
tions X.3, X.28 and X.29" Data Transfer newsletter, 
Transmission #9, April 1984, Omnicom Information 
Service. 
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TABLE 1 — X.3 PARAMETER VALUES 


* = default value 
# = not supported 
% = additional to X.3 standard 


O | not possible 
/B *27 | ESC character 
1-26, 28-255 | optional values 


0 | noecho 

ih —_— 

Data forwarding full packet only 
alphanumerics 
Carriage return 
ESC, BEL, ENQ, ACK 
carriage return, ESC, BEL, ENQ, ACK 
DEL, CAN, DC2 
ETX, EOT 
carriage return, EOT, ETX 
HT, LF, VT, FF 
all other characters below 32 
no timer 
default value 
delay values in approximately tenths of a 
second 
no flow control 
X-ON/X-OFF (data transfer) 
X-ON/X-OFF (data transfer and command) 
flow control with RTS line 
no service signals 
transmit service signals 
transmit service and prompt sigs 
network dependent format service sigs 
no action 
interrupt packet 
reset packet 
indication of break service signal 
interrupt and indication of break 
escape from data transfer state 
discard output to terminal 
1 + 4 + 16 combined 


ee discard ve normal data delivery 
discard output to terminal 
[See rune of 
125 number of nulls inserted after CR 
- Jhscaaclemallllal rnb of 
ott number of characters per line 
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TABLE 1 — X.3 PARAMETER VALUES 


* = default value 
# = not supported 
% = additional to X.3 standard 


0 | 110 bit/s 
1 | 134.5 bit/s 
2 | 300 bit/s 
3 | 1200 bit/s 
4 | 600 bit/s 
5 | 75 bit/s 
6 | 150 bit/s 
7 | 1800 bit/s 
8 | 200 bit/s 
9 | 100 bit/s 
10 | S50 bit/s 
75/1200 bit/s 
12 | 2400 bit/s 
13 | 4800 bit/s 
14 | 9600 bit/s 
15 | 19200 bit/s 
48000 bit/s 
56000 bit/s 


64000 bit/s 


no flow control 
X-ON/X-OFF flow control 


12 | Flowcontrol to terminal *0 
1 
X %2 | flow control using CTS line 


13 | Line feed insertion None 
after carriage return to terminal 
after carriage return from terminal 
after echoed carriage return 
values 1 +4 
values 2 +4 
values 1 + 2 + 4 (data transfer only) 


: ; rp 0 
1 
2 
4 
5 
*6 
5 
I tee rere 35 | mn 
1-255 | number of nulls after line feed 
15 | Editing nh off 
on 
Character delete g *8 | BS (backspace) character (control-H) 
~  Q-7, 9-127 | other characters 
17 | Line delete WS *24 | CAN character (control-X) 
incall Casale Dice 


other characters 
inal aida ‘ 
0-17, 19-127 | other characters 
19 | Editing service signals > 0 
“ 
#8 


no editing service signals 


editing for printing terminals 
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editing for display terminals 
editing using characters from range 32-126 


TABLE 1 — X.3 PARAMETER VALUES 


* — default value 
# = not supported 
% = additional to X.3 standard 


all characters echoed | 
no echo of carriage return 

no echo of LF 

no echo of VT, HT, FF 

no echo of BEL, BS 

no echo of ESC, ENQ 

no echo of ACK, NAK, STX, SOH, 
EOT,ETB, ETX 

no echo of editing characters 

no echo of all characters in columns 1 & 2 
plus DEL 
no parity detection or generation 
parity checking 

parity generation 

value 1+2 
no page wait 


128 
Parity treatment #0 
#1 
#2 
S #3 
*0 
number of line feed characters before wait- 


22 | Page wait — O 
| 1-255 
ing 
%23 | Buffer cushion 5 *80 | number of characters in cushion 
2-79, 81-254 | other values 
%2A | Linked timeouts ) *16 | maximum consecutive timeouts linked 
1-15, 17-255 | other values 


ro) 
Unlinked timeouts S *5 | maximum consecutive timeouts when not 
linked 
1-4, 6-255 | other values 
%26 | Line timeout of *10 | approximately 5 seconds 
1-9, 11,255 | other values 


Duplex line control o half duplex line control 
always assume that channel is clear 
full duplex 
%28 | Clear to send delay x *32 | approximately 1 second 
: 1-31, 33-255 | other values 


Link control normal 


links to other nodes not permitted 


D 

© 
50_| Unused Tink contol parameer 0) ae 

Oo 

O 


% Ceemeees te 
%31 | Autobaud control use fixed UART defaults 
AutoBaud 
%32 | Received packet forwarding 0 | only pass packets when linked 
*1 | pass unlinked packets 
%33 | Maximum packet length 2 ~*200 | maximum output packet data bytes 
3-199, 201-250 | other values 

Network header 2nd byte O *Q | NH second byte is 00 

1-255 | other values 


Unusednetwork conwolparameier Of S| 
Lo a Ee) 
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TABLE 1 — X.3 PARAMETER VALUES 


* — default value 
# = not supported 
% = additional to X.3 standard 


Parameters 


Values 


————— SSS 


%36 | Unused network control parameter 


Unused network control parameter 
%38 | Unused network control parameter | |  — | 
: Be 


39 | RLSD (CD) line control 
STE 


From Gateway 
The ARRL Packet-Radio Newsletter 
Volume 1, No. 8, Nov. 20, 1984. 


ARRL AND PACKET RADIO 


The "Proposal for Packet-Radio Development 
Program" mentioned in Minute 99 is a document 
authored by Paul Rinaldo, W4RI, that details recent 
growth in packet radio, the goals of packet-radio 
experimenters, and actions that the ARRL might take 
to assist packet-radio development. While it does not 
attempt to allocate funds or personnel to packet-radio, 
it ends with the following list of recommended 
actions: 

1. Board Actions 
a. Approve the AX.25 link-layer protocol. 
b. Support the Digital Committee. 


c. Approve ARRL laboratory support of packet 
radio 

d. Approve San Francisco as the site for the 
Fourth ARRL Amateur Radio Computer Net- 
working Conference. 


e. Encourage more Board Members to get on the 
air with packet. 
2. Headquarters Actions 


a. Publish the AX.25 Amateur Packet-Radio 
Link Layer Protocol document. 


b. Develop a nontechnical flyer on packet radio 
for answering mail inquiries and as a handout 
for field use. 


c. Publish more packet-radio articles in QST, and 
do club profiles on clubs contributing to 
packet radio. 
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always on 
indicates if link is established 


mask off high order bit 
pass all 8 bits in each byte 
range permitted 


d. Work with the Connecticut Section Leadership 
Officials to develop a demonstration "model 
section” with a variety of packet-radio ser- 
vices. 

e. Continue ARRL lab technical support of 
packet radio experimenters, particularly in 
preparing descriptions of designs for League 
publications 

f. Configure W1AW for packet-radio teleport 
Operation and conduct tests with other 
teleports under a special temporary authority 
granted by the FCC. 

g. Produce a slide show or video tape on packet 
radio. 

3. Ad Hoc Committee Actions 


a. Coordinate and support experiments leading to 
an early agreement on network and transport 
protocols. 


b. Develop a message protocol capable of sup- 
porting Amateur Radio emergency communi- 
cations, NTS traffic, inter-PBBS exchanges, 
and other electronic mail applications. 


c. Work towards developing standards for other 
protocol layers. 


d. Encourage development of higher-speed 
packet radio systems. 


e. Investigate ways of reducing the cost of 
packet radio to amateurs. 


Obviously, not all of these items will be acted 
on immediately, and some may give way to more 
fruitful or critical projects. However, this program 
does indicate that the ARRL Board recognizes the 
potential of packet radio to improve Amateur Radio, 
making it more interesting, advanced hobby and a 
more effective tool for public service. 
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VANCOUVER DIGIPEATER 


The Vancouver Amateur Digital Communica- 
tions Group (VADCG), one of the groups that 
pioneered amateur packet radio, has installed a 
145.65-MHz wide-coverage digipeater on Burnaby 
Mountain. The equipment is a VADCG TNC with 
repeater and beacon software, an IC-22S transceiver, 
and a multi-element beam aimed south (toward the 
U.S.). Coverage is good into Bellingham, Washing- 
ton, and reports have been received from as far south 
as Edmonds, Washington. Local coverage includes 
greater-Vancouver and the Fraser Valley. There are 
about a dozen Canadian stations active on the digi- 
peater, and there are several active stations in Belling- 
ham. Others are still in the process of bring up TNC 
boards and modifying VADCG TNCs to support the 
V.2 protocol. Many stations have Xerox 820 boards 
providing network services, and WA7IPX has had his 
Xenix system on line. Packet operators visiting the 
Vancouver area are encouraged to use the machine. 


From VE7DPM .- 


[ Note: The VE7PKT. ‘digipeater repeats all protocols, 
that means AX.25 as well as V-2 (and V-1) ] 


From Gateway 
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PACKET RADIO FOR THE IBM PC 


Jack Botner, VE3LNY, has developed a peri- 
pheral card for the IBM PC that uses an 8273 high 
level data link controller (HDLC) integrated circuit to 
provide packet-radio I/O for the PC. The card allows 
the PC to access the HDLC chip through polling, 
interrupts or DMA. If you are an experimenter and 
own an IBM PC, you will be interested in this project. 
Complete details, including a circuit diagram, appear 
in the December issue of QEX, the ARRL 
experimenter’s exchange. Although the article does 
not cover software to operate the controller, the 
AX.25 software written by Phil Karn, KA9Q, could 
be modified to run on the PC. 


From QEX. 
[ Ed’s note: VE3LNY HAS V-2 software for the card ] 


Page 20 


From Gateway 
Vol. 1/No. 14, Jan. 26, 1985 


COMPUSERVE HAMNET 


If your interest in data communications is grow- 
ing, and you would like to take part in a continuing 
discussion of issues in packet radio, consider joining 
HAMNET on Compuserve. If you are already on 
Compuserve, type "GO HOM-11" to get to HAM- 
NET. If you would like to get on Compuserve, con- 
tact a local computer store and ask about it. Com- 
puserve connect fees are reasonable, and the HAM- 
NET is a well-run discussion of all topics in Amateur 
radio. Section 9 in HAMNET is devoted exclusively 
to packet radio, RTTY, and AMTOR. Messages and 
news items for Gateway can be directed to Com- 
puserve account 75105,737. 


[ You can reach VADCG through 72416,3437 
(VE7DPM) ] 


From Gateway 
Volume 1, Issue 19 May 7, 1985 


XEROX 820 ROUNDUP 


RAM, two serial I/O ports, a parallel I/O port 
and a disk controller. In 1984, Xerox made these 
computers available at surplus prices, and packet 
radio experimenters throughout the U.S. bought them. 
With hundreds of Xerox 820s in the hands of pack- 
eteers, it was not long before packet radio applica- 
tions software was available. The following is a list 
Xerox 820 software and hardware produced “by and 
for packeteers." 


The MailBox and GateWay programs written 
by Hank Oredson, WORLI, work with a Xerox 820, 
8-inch disk drive(s) and one or two TAPR TNCs. The 
MailBox is an excellent packet radio bulletin board 
system, with Hank’s message forwarding routines, file 
uploading and downloading and extensive user log- 
ging. The MailBox can be connected to two TNCs to 
provide a message-storage node for two networks. If 
you use 2 TNCs, the GateWay program allows a sta- 
tion connected to one of the TNCs to initiate connec- 
tions using the other TNC. The GateWay is most 
often used to link VHF networks to HF stations but 
can also be used in areas where there is activity on 
two VHF frequencies. To receive the latest version of 
the MailBox and GateWay, send an 8-inch disk, a 
disk mailer and return postage to: 
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Hank Oredson, WORLI 
19 North Hill Road 
Westford, MA 01886. 


The ’820 has enough parallel and serial I/O 
ports to be used as a TNC, if you have the necessary 
hardware and software. There are two hardware 
modifications used to make the Xerox handle the 
HDLC protocol that is the basis of AX.25. The "FAD 
board” is an HDLC board that replaces one of the 
parallel YO chips on the Xerox with a Z8530 serial 
communications controller (SCC). This board, 
designed by Howard Goldstein, N2WX, was first 
described in the newsletter of the Florida Amateur 
Digital Communications Association (FADCA). 
Since then, the Tucson Amateur Packet Radio Corp. 
(TAPR) has made bare PC boards for the FAD board 
available. The original run of these boards has run 
out, but more should become available this summer. 
The Z8530 chip is available (in limited quantity from 
FADCA). 


FADCA 
812 Childers Loop 
Brandon, FL 335ll. 


The second approach to HDLC is to use a serial 
VO (SIO) chip (already on the Xerox 820) and an 
external state machine. The state machine recovers 
clock information and converts data to and from the 
NRZI format used by AX.25. The state machine 
schematic and listings of the state machine PROM are 
available from Gateway for an s.a.s.e. 


When you have selected hardware for your 
Xerox 820, there are several software choices. FAD- 
pad is a TNC program, written by N2WX, that sup- 
ports a single AX.25 link at a sustained data rate up to 
9600 bit/s. The software is the same as that in the 
TAPR TNC 2, and the user interface is compatible 
with most TAPR commands and procedures. To use 
FADpad, you must have a FAD board. FADpad is 
available as a pair of customized 2764 EPROMs 
from: 


Ted Huf, KANTA 
1829 NW Pinetree Way 
Stuart, FL 33494. 


A CP/M .COM file for FADpad is available if 
you send an 8-inch disk and sufficient return postage 
to: 


Howard Goldstein, N2WX 
POB 905 
Melbourne, FL 32901. 
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Phil Karn, KA9Q, has written a C program that 
can support multiple simultaneous AX.25 connections 
on a single Xerox 820. This program mns on the 820 
under CP/M with either the FAD board or the SIO 
and state machine. Send an 8-inch disk and return 
postage to: 


Phil Karn, KA9Q 
25B Hillcrest Rd. 
Warren, NJ 07060. 


The ’820 can also be used — without disk 
drives, monitor or keyboard — as a digipeater. Jon 
Bloom, KE3Z, has developed multiport digipeater 
software for the Xerox. The software can be used to 
link networks different frequencies, or it can be used 
as a simple single-port digipeater. It uses the SIO and 
two state machines for HDLC output. To receive this 
software, send a disk to Gateway. 


Where do you get a Xerox 820 if you want one? 
Since the computers are no longer produced, supplies 
are erratic, but persistent calling to the Xerox outlet 
will usually turn some up. Their phone number is 
(214) 960-3367. 


If you want more information about the Xerox 
820, you may be interested in Micro Cornucopia 
magazine. "Micro C" is dedicated to single-board 
computers and has a Xerox column. 


Micro Cornucopia 
P.O. Box 223 
Bend, OR 97709 


Remember, the ARRL and Gateway in no way 
endorse the above products. The people making this 
software and hardware available are amateurs, not 
commercial vendors; send a disk if you want one in 
return; include sufficient postage; be patient. 


Ed. 


MEMORY EXPANSION 
FOR THE VADCG TNC-1 


In the issue 9 of the PACKET, modifications 
were described to increase the on-board EPROM 
Capacity from 4-Kbytes using 2708s to 8- or 16- 
Kbytes using 2716s or 2732s respectively. The 
recommended choice is the 2732 option, if you want 
to install the current software with SADCG Master 
Control Subsystem, VWADCG V-2 (with X.3/X.28) 
and ARRL AX.25 (AMRAD Version 5.x) protocols. 


Here are 2 alternative methods to expand TNC 
memory. 
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* SADCG EPROM EXPANSION BOARD 


To expand the capabilities of the 
VADCG TNC, it is necessary to increase the 
EPROM capability beyond the 16k of a unit 
with standard memory modifications. There- 
fore, the EPROM Expansion Board was 
designed. It provides an extra 16k (4 x 2732’s). 
The SADCG is planning to make a kit available 
if sufficient interest is shown. 


The board is designed to mount along the 
side of the TNC, using the same mounting holes 
and board stand-off spacers as the min board. 
The board is available from the SADCG via 
VK2YME. 


Contact: 

Sydney Amateur Digital 
Communications Group 

P.O. Box 231 

Frenchs Forest, NSW 2086 

Australia 


¢ AMRAD DAUGHTER BOARD 


From: Amateur Radio Research and 
Development (AMRAD) and Terry 
Fox, WB4JFI 


Subject: New Life for an Old Friend 


The Amateur Radio Research and 
Development Corporation, AMRAD (origina- 
tors of the now popular AX.25 Level 2 proto- 
col) is pleased to announce that it is now possi- 
ble to expand the original Vancouver Terminal 
Node Controller board’s memory without rais- 
ing an X-Acto knife! AMRAD President Terry 
Fox, WB4JFI has designed a daughter board 
that plugs into an unmodified VADCG TNC 
and expand the TNC memory from 4 kilobytes 
each of EPROM and RAM to up to 32 kilobytes 
of each. In addition, three software programm- 
able timers are also provided. One timer is 
used to provide the clock for the 8273 (HDLC 
chip) on the VADCG TNC. The other two 
timers are used to generate timed interrupts for 
the VADCG TNC (8085). One timer generates 
maskable interrupts (INTR pin), while the other 
timer generates non-maskable interrupts (TRAP 
pin). These timers can be used to give the pro- 
grammer a more accurate method of controlling 
protocol functions. 
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Write: 


AMRAD 
PO Drawer 6148 
McLean, VA 22106-6148 


or: 


Terry Fox 

WB4JFI 

1819 Anderson Rd. 

Falls Church, VA 22043 


For those in need of a VDS-1 daughter board, 
you can order one from the following address. The 
cost is $25.00 plus $2.25 to cover postage. 


Technetronics Systems, Inc. 
ATTN: Charles O. Phillips 
6134 Columbia Pike 

Falls Church, VA 22041 


AMATEUR PACKET RADIO 
DEVELOPMENT 
A Pioneer’s Perspective 


Doug Lockhart, VE7APU 


Paul Rinaldo, W4RI, the chairman of the ARRL 
Ad Hoc Digital Committee said a while ago, "There 
may be 10,000 packet users by this time next year." 
Most of these will be in the U.S.A. I tend to agree 
with this rough estimate. I know that the number of 
TNCs being sold in one week or less nowadays 
exceed the number of TNCs sold in the whole year of 
1980 and the rate is still increasing. It is well known 
that the number of ‘active’ Amateurs is much less 
than the number of licence holders — how much 
depends on one’s interpretation of the word, ‘active’. 
Using my own estimate of activity as only about 10% 
of licence holders, would indicate that there are 
roughly about 40,000 ‘active’ U.S. Amateurs. In 
other words, about 25% of ‘active’ U.S. Amateurs 
will own TNCs in less than a year. 


The growth of Amateur packet radio is behav- 
ing very much like the classic growth pattern of 
animal populations, fads, etc. Typically, populations 
start off very slowly, but accelerate exponentially, 
eventually growing at an extremely rapid rate until 
running into some natural limitation causing the curve 
to peak out and subsequentially collapse as fast as it 
rose. Many things have this characteristic growth pat- 
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tern and I believe Amateur packet radio growth will 
also fit this pattern. 


So, where is Amateur packet radio on this 
growth curve? It has already entered the rapid growth 
stage and is virtually out of control at the present 
time. The signs are everywhere. Consider the large 
number (a dozen or so) of commercial manufacturers 
of TNCs in the market now. Packet radio is the hot- 
test item in Amateur radio — look at the advertise- 
ments. I have been hearing stories such as the one 
which said that Heathkit sold its entire three month 
production of TNCs in only a couple of weeks after 
coming on the market or that a manufacturer brought 
a large supply of TNCs to the Dayton Hamvention but 
sold all of them on the first day, etc. 


I estimate that in the U.S. packet radio growth 
will saturate sometime in 1986 or 1987 after which it 
will decline rapidly following the usual pattern of 
fads. While it may be obvious that the growth will 
saturate (the numbers above show that there is a limi- 
tation in the number of active Amateurs) it may not be 
obvious that there will be a decline but the indications 
are there if one looks. Paul Rinaldo has expressed his 
concern about what Packet Radio is going to offer the 
average Ham next year. He says, "If all they have is 
level 2, how long will they be happy — particularly if 
they have some idea of packet’s potential?" His con- 
cerns are very valid considering the progress (or lack 
of it) that has been made in the last few years. Paul’s 
particular complaint is the lack of progress on the net- 
work level protocols that we will need in the future. 
If one looks at the people who were in packet radio 
earlier, you find many no longer active. Some areas 
have already passed through a complete growth cycle. 
Initial interest will turn to boredom unless new things 
become available. 


Unfortunately, the development of packet radio 
is now almost completely out of the hands of the 
developers and we are in a time of uncontrolled 
growth and mass marketing with little concern for the 
longer term needs of the users. The TNCs and 
software packages that are in use and being sold to the 
majority of Amateurs today is going to be what is in 
use when the growth curve peaks in a year or two. 

When I first started developing packet radio 
equipment and software for the Amateur I realized 
that eventually we would get to this stage of popular- 
ity. What is so disappointing to me is the low techni- 
cal level of hardware and software that is being 
delivered to the masses. In the beginning I was 
expecting that at this point in the growth curve we 
(developers) would be supplying an efficient, reliable, 
widespread, high speed packet radio system to the 
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average Amateur but in fact, in many respects, the 
mass-marketed system is inferior to the state of Ama- 
teur packet radio five years ago. To justify this state- 
ment and to find out how we got into this situation 
requires some historical background. 


HISTORY 


The first Amateur Packet Radio experimenta- 
tion anywhere in the world started in Canada early in 
1978 after some encouragement by the Department of 
Communications (DOC). The pace of this experi- 
mentation quickened when the DOC changed the 
regulations to legalize such experimentation in the fall 
of the same year. It was not for approximately 18 
months later that experimentation in this mode began 
in the United States mainly due to extensive “mission- 
ary’ work on the part of several Canadians. I, myself, 
spent a great deal of time and my own money visiting 
and talking, demonstrating and writing letters to 
groups and individuals all over the U.S. The 
encouragement and example we gave to some U.S. 
amateurs resulted in changes in U.S. amateur regula- 
tions to permit packet radio experimentation in that 
country. The Canadian work served as a ‘catalyst’ 
which won U.S. Amateurs the right to use the ASCII 
code and packet radio in their country and now in 
many other countries as well. It is very likely that 
there would be no Amateur packet radio in the U.S. 
today but for the efforts of these Canadian pioneers. 


Nowadays, few U.S. Amateurs are aware of 
this Canadian contribution. In fact, many Amateurs 
believe that Amateur packet radio started in the U.S. 
when actually it began in Canada fully 18 months 
before anything was done in the U.S. and that start in 
the U.S. was directly due to the Canadian work. 
There seems to be almost a conscious effort to rewrite 
history. 

What did Canadian experimenters accomplish 
in this 18 months period? Quite a bit. By the fall of 
1979 there were three major groups in Canada 
independently developing hardware and software for 
packet radio. The groups were located in Montreal, 
Ottawa and Vancouver. 1979 has been the greatest 
year for Amateur packet radio so far. Almost all the 
techniques being used today were used for the first 
time by one or another of these groups in that year. 

The Montreal group had developed a CSMA 
CD protocol using start-stop ASCII codes and was 
using AFSK modulation at 1200 and 2400 Baud on 
the 220MHz. band. 

The Ottawa group was using a polling protocol 
also with start-stop ASCII and using multiple virtual 
connections through a station node. They were using 
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9600 Baud FSK modulation on 220MHz. using VHF 
Engineering transmitter and receiver strips. Their 
entire network was operating at 9600 Baud. This 
should be compared to the situation in the U.S. now in 
mid 1985 where 9600 Baud experimentation on 
220MHz. using FSK modulation on modified Ham- 
tronics receiver and transmitter strips. 


The Vancouver group (VADCG) had 
developed and produced what they called a “Terminal 
Node Controller’ board (TNC) using bit-oriented pro- 
tocols (HDLC/SDLC) and was using AFSK modula- 
tion at 1200 Baud on 144MHz. for testing protocols. 
They had also developed a Station Node and Station 
Node Controller (SNC) and were using a CSMA CD 
protocol and dynamic addressing establishing virtual 
connections through the station node (packet switch). 

I will say more about the Vancouver Group’s 
development efforts for a couple of reasons. Firstly, I 
started this group in January of 1979 and so know 
much about its history and objectives and secondly, 
because it was the VADCG’s system that was copied 
and is being used world-wide for Amateur packet 
radio today. 

After we developed the TNC board, some Ama- 
teurs in the Hamilton, Ontario area wished to use it 
but they did not have a station node or SNC or money 
to put one on the air. They asked that I write a pro- 
gram which would enable them to communicate 
directly from one TNC to another instead of through a 
station node so that they could test the operation of 
the TNCs before they built the station node. So, in 
early 1980 I wrote a simple but efficient link level 
protocol that would temporarily let them do this test- 
ing. This protocol became known as the “Vancouver 
protocol’ but we call it “V-1’ now to distinguish it 
from other protocols developed in Vancouver. 

It is basically a copy of the ‘temporary’ system 
we were using in early 1980 that is being mass- 
marketed today. The original concept and develop- 
ment of a dedicated board for Amateur packet radio 
(TNC), the use of bit oriented protocols as opposed to 
start-stop protocols, the use of 1200 Baud Bell-202 
AFSK on 144MHz. all were originally developed for 
packet radio by the VADCG in 1979. The mass- 
marketed TNCs today are essentially the same as the 
original system. They still don’t have anything but a 
link level protocol not even as efficient as the ‘tem- 
porary’ one developed in early 1980. 


In the five years since the rapid development of 
1979 by these Canadian groups we seem to be going 
nowhere if not backwards. The U.S. and most other 
countries are not using the higher speed (9600 Baud) 
and more efficient modulation system (FSK) 
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developed by the Ottawa group or their polling proto- 
col. Many of the good ideas from Montreal have 
been ignored. The virtual connection protocols used 
in Ottawa and Vancouver have been ignored even 
though the hardware designs and software were pro- 
vided freely by these groups. 


What is the reason for this lack of progress and 
the lack of variety in packet radio techniques today? 
I, for one, expected the U.S. to build on the Canadian 
developments once they started using packet radio. 
After all, the population is much higher and the U.S. 
has a great reputation in high technology. 


Technological progress needs a certain type of 
environment. Such an environment was present in 
1979 in Canada. There were three development 
groups operating completely independently of one 
another. In fact, for some of the time, they were not 
aware of the existence of the other groups. There 
were no standards to adhere to, no consulting commit- 
tees, etc. They worked with the goal of improving 
Amateur digital communication techniques and were 
free to do it any way they chose without interference. 
In such an environment, progress thrives. 


When packet radio came to the U.S. the above 
conditions didn’t exist. The software and hardware 
used in the U.S. for the first year or two all came from 
Canada (the VADCG to be specific) and the ‘tem- 
porary’ Vancouver protocol almost immediately 
became the standard and only protocol used there. 
The goal in the U.S. at that time was to ‘catch up’ 
with the Canadians. In such an environment, there 
was little or no technical development. Technical 
development in Canada also slowed down at this time 
but for a different reason. In trying to supply the U.S. 
demand for information, TNC boards, modem boards 
and software; the VADCG was put under a severe 
financial and manpower strain and development suf- 
fered. This was a blow that the VADCG has never 
fully recovered from. I am only guessing but I think 
that development in Ottawa and Montreal slowed 
down at this time when the development groups there 
saw the spread of the VADCG system in the U.S. 
rather than the systems they were working with. This 
would have been disheartening to me especially since 
certain aspects of their systems were superior. 


At this time the Vancouver protocol was the 
only one being used in the U.S. and I was approached 
a number of times by people who wanted to proclaim 
this protocol as an international standard. I objected 
to this idea as I considered this protocol to be unsuit- 
able as a standard and the very idea of a standard at 
this early stage of development would be detrimental. 
I still feel this way in 1985. 
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Although the development environment in 
Canada had deteriorated, it looked like it would 
improve in the U.S. After all, we were providing a 
good development system for packet radio — an 8085 
based TNC and source software and drivers for it. 
The 8080 family was the most popular microproces- 
sor at the time and the software was provided for a 
standard CP/M system which was the most common 
microcomputer development system available. 
Things seemed to be going OK in the U.S. and some 
changes were being made in the software that had 
been provided. Then the mistakes started to happen... 


At the beginning of 1982 the Tucson Amateur 
Packet Radio Corporation (TAPR) announced that it 
would be providing a TNC board at half the price of 
the VADCG TNC board. At that time the VADCG 
kit was being delivered in the U.S. for $147. Even 
though the TAPR Alpha board wasn’t delivered for 
several months and came nowhere close to being half 
price, this announcement stopped sales of VADCG 
TNCs in the U.S. while waiting. The Alpha board 
was based on the 6502 microprocessor. The board 
only lasted a few months and TAPR no longer sup- 
ports it even though many Amateurs purchased it. 
This attempt at replacing a board which allowed 
software developers something to work with caused a 
great deal of disruption to the development process. 


After the abandonment of the Alpha board in 
the fall of 1982, the Beta board was produced by 
TAPR for about $250 which was based on the 6809 
chip — a microprocessor for which there was virtu- 
ally no way for a software developer to use. Even 
TAPR had to develop software on a mainframe com- 
puter which had a Pascal cross compiler. This board 
proved quite popular in the U.S. almost to the exclu- 
sion of all other development systems. 


After this, the TAPR TNC kit was produced 
which also used the same chip, the 6809. Over 2000 
of these kits have been sold by TAPR in several dif- 
ferent countries. They were sold as black boxes. 
Software development up to now has been almost 
non-existent for these TNCs because of the scarcity of 
microcomputer development systems for the chip. It 
is no wonder that software development has made lit- 
tle progress in the U.S. and will likely make little pro- 
gress in countries exclusively using these TNCs. 


TAPR has sold off all these TNCs and is 
switching to one based on the Z-80 microprocessor. 
This is a good move as the Z-80 is compatible with 
common microcomputer development systems and 
with the 8085 microprocessor used in the VADCG 
TNC — maybe developers will be able to work again. 
(Why wasn’t this done in the first place?) It seems to 
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be significant that virtually all the software develop- 
ment for packet radio TNCs in the U.S. has been 
made on systems based on the 8080/8085/Z-80 family 
of microprocessors while virtually nothing was 
accomplished for the 6809 in a period when the 6809 
was the most prevalent microprocessor in TNCs. 
Does this mean we have seen the last of the 6809 
TNC? No, because before TAPR discontinued the 
6809 boards, they licenced the production of the 
board and software to several commercial manufac- 
turers and they are now being mass marketed in large 
numbers and will be for some time to come. 


What was the objective in basing the TAPR 
TNC on the 6809 chip and developing the software on 
a system not available to any other software develop- 
ers? I don’t know but it was said by a TAPR 
representative that it was a good thing it was done this 
way because it would prevent anyone from tampering 
or modifying the software. I don’t know if this was 
the reason or not but it demonstrates the wide gap in 
opinions as to what is best for Amateur Packet radio. 


There is still hope for these TNCs as there are 
some new systems available for the 6809 Assembler 
programmers nowadays. There are rumours of an 
independent development group in the U.S. which is 
re-coding and improving the software for these 
boards. Although it is impossible to make up for lost 
time, we wish them every success. 


Most Amateur software developers are in an 
almost impossible situation now. They cannot do any 
development on the TNC in common use but if they 
do any development on anything else, then the huge 
user base cannot use it because they cannot change. 
The developers who gave packet radio to the Amateur 
fraternity are being placed into the situation where 
they will be disliked by the user community because 
they represent a threat to the equipment investment 
made by that community. In any case, development is 
being passed out of the control of the Amateur 
developers and into the hands of commercial interests 
now. 


This latter undesirable situation need not have 
occurred so soon but for the actions of the ARRL Ad 
Hoc Digital Committee which voted to endorse the 
AX.25-L2 protocol in order that commercial 
manufacturers could begin to manufacture packet 
radio equipment for the Amateur market. This object 
has been stated and written by a number of committee 
members and the chairman of the committee. Lyle 
Johnson, for example, endorsed the proposal writing, 
"It implies a stable base for commercial ventures 
marketing their wares." Is this really the purpose of 
the committee? I thought the objective was to assist 
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Amateur packet radio development not to pass this 
responsibility off to commercial interests. With the 
full potential of packet radio a long way off, what we 
need is development and variety, not stability and 
standardisation. Stability is the antithesis of develop- 
ment. However, I seem to be a singular minority in 
the committee as being the only one who voted 
against it. The chairman made the statement before 
the vote was taken that it would be seen as a failure of 
the Committee if the Committee did not approve a 
level 2 protocol or approved more than one level two 
protocol. Paul went on to say that the ARRL Board 
of Directors would likely dissolve the Committee if 
either event occurred. 

This incredible ‘one and only one’ concept 
prevented any serious consideration of V-2. This was 
in spite of the fact that V-2 had a published protocol 
document, was being used in at least three countries, 
had been tested and found to be more efficient than 
AX.25, had implementations which included the 
X.3/X.28 protocol which AX.25 implementations 
didn’t have and still don’t, complied fully with the 
ISO reference model for level 2 which AX.25 doesn’t 
and had been implemented on some systems for 
which AX.25 hadn’t been, etc. The published proto- 
col specifications for V-2 were good enough that a 
completely independent implementation of V-2 on an 
IBM PC had been made and when the two implemen- 
tations were tested together, they were able to com- 
municate successfully. 


This ‘one and only one’ attitude doesn’t prevail 
in International Standards Organisations. Many dif- 
ferent protocols are approved which do similar things. 


Consider the various LAN protocols that ISO is docu-_ 


menting. The usual purpose of standards committees 
is to disseminate information on all standards in use, 
not to endorse one to the exclusion of all others. Why 
does it have to be this way in Amateur packet radio? 


Intolerance of any other efforts like attempts to 
develop a better protocol than AX.25 such as V-2 is 
evident in another quote by Lyle Johnson, the 
president of TAPR, "If the committee sees fit to adopt 
V-2 over AX.25-L2, so be it. TAPR will probably 
conform to the majority in the overall best interests of 
packet radio. By the same token, if the committee 
sees fit to adopt AX.25-L2 over V-2, I expect to see 
VADCG conform." Mr. Johnson does not appear to 
be concerned about what is the best protocol for Ama- 
teur packet radio only that everyone conform to what- 
ever the Committee votes for. He seems to think he 
knows what the “overall best interests of packet 
radio" are or at the very least assumes that whatever 
the majority of committee members votes for is 
automatically in the overall best interests of Amateur 
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packet radio and so he will conform with something 
that he personally did not think was in the overall best 
interests of packet radio. 


Since the majority of the Committee voted to 
approve AX.25-L2 I am not exactly sure what we in 
the VADCG are expected to conform to. At the 
present time, the VADCG TNC is the only one which 
can run V-1, V-2 and AX.25 at the same time. Any 
protocol can be selected from a menu. Is this 
sufficient conformity to satisfy Mr. Johnson or are we 
expected to develop more software for a protocol we 
don’t think is very good (AX.25) in order to conform? 


It is ironic that the critics of our lack of confor- 
mity are reaping the benefits of that very lack of con- 
formity. One of many possible examples: When we 
started the development of packet radio in 1979 there 
was a lot of pressure to conform to standard Amateur 
practice and use start-stop protocols for communica- 
tion. Bit oriented protocols had never been used in 
Amateur radio even though they have become a stan- 
dard in Amateur packet radio worldwide today. Do 
you think it was easy developing bit-oriented packet 
radio in that environment? It wasn’t. I had to fight 
hard against the vast majority of opinions in order to 
be able to improve the standards of Amateur Digital 
Communications. Also, think what it would have 
meant to have to go through a ‘one and only one’ 
committee at that time. We would still be only using 
start-stop protocols. 


It seems to me that the ARRL Digital Commit- 
tee is trying to take on a responsibility that it is not 
qualified to do in deciding what efforts are good and 
bad for Amateur packet radio. It is all right for an 
individual to have these opinions but it is very 
dangerous when a committee sets itself up to do this 
job. Regulation and control of Amateur packet radio 
development should not be the responsibility of the 
Committee. The Committee should be taking an 
even-handed approach and disseminate information 
on all protocols instead of promoting some and 
suppressing others. 


In the U.S. and worldwide, progress appears to 
be confused with proliferation and many packet radio 
organisations have jumped on the bandwagon of 
mediocrity. The slogan, “Join the Packet Radio Revo- 
lution” seems to mean, "Buy our boards, use our sys- 
tem." It is overused so much in all the advertising 
literature of commercial manufacturers or whenever a 
new TNC is being peddled. 

The VADCG is a small non-profit research and 
development group. It intends to develop packet 
radio systems that the developer can use as it has in 
the past. In particular, we do not intend to develop 
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systems for the end user that developers cannot also 
use. 


Hardware projects that the VADCG is working 
on currently include an upgraded TNC which pro- 
vides more flexibility for development and a more 
efficient and flexible modem than we previously had. 
Software development work is being done on provid- 
ing multiple linking capability for the TNC, new level 
2 (Datalink), level 3 (Network), and level 6 (Presenta- 
tion) protocols are also being worked on. We are not 
leaving the users of our board with only one protocol 
but are providing software for all the protocols we 
can. This includes V-1, V-2 and AX.25 and will 
include the new protocols we are working on. The 
software is not just supplied in burned in EPROMs 
but we also supply all source files in a form that 
developers can use and change as they see fit. 


It is sad to think of the things we could have 
done in the last few years but for the mistakes that 
were made, the developers who have given up in frus- 
tration, etc. We could have built an environment 
which would encourage the development of the full 
potential of Amateur packet radio instead of 
discouraging such development. The end user is also 
a big loser too but I don’t think he has any realization 
of what has been lost. 


Perhaps my dream for Amateur packet radio 
will be realized but it has been set back many years 
now. Some developers are still working even under 
these difficult conditions. I hope we get out of the 
one step forward, two steps backward development 
that has been going on and we can begin supplying 
the most advanced packet radio technology to the end 
user rather than proliferating only the lowest levels of 
packet radio technology. 


I hope that other countries, just beginning to get 
involved with Amateur packet radio will be able to 
understand and avoid the mistakes that have been 
made in the U.S. I hope that they may avoid the 
‘standardise at any cost’ trap and are able to create in 
their countries an environment suitable for packet 
radio developers and experimenters. (The Swedish 
Softnet User’s Group deserves special praise in this 
regard!) The end user may not realize it, but it is in 
his best interests to do this too. 
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A Five Year Review of the nine 
previous issues of THE PACKET. 


Issue 1, May 1980, "Packet Radio Newsletter" 

* World’s first public demo of VADCG packet 
radio system on April 26, 1980 at CARF Sympo- 
sium, New Westminster, BC. The first Station 
Node working at VE7APU QTH, and the first 
VADCG TNC #1 node at the site. 

e Second, third and fourth public demos on: June 
18/80 meeting at Simon Fraser University, July 
5,6/80 Maple Ridge Hamfest and end of July 
ARRL Convention at Seattle, WA. 

* Most activity locally on 2M, terminal to terminal 
using 1200 baud AFSK, on 145.65 MHz. Station 
Node on at irregular intervals since then. 

e 20-M beacon on 14.0765 MHz, every 5 mins for 
35 secs heard across Canada, usually good recep- 
tion in Ontario, Canada. 

¢ First run of 25 TNC boards selling for $30. Only 
3 left at time of writing. Kit of all parts for TNC 
board for $285. 


Issue 2, September 1980, now called "The Packet" 

e Article describing TNC hardware and software. 

¢ Report on demo at July ARRL convention in Seat- 
tle, using local FM repeater, established commun- 


ication with station node computer in Vancouver, 
Canada, 180 miles North. 


e Ken Slauso, WB7SFO, was Seattle contact. 
Planned to form a packet radio interest group in 
Washington State. 


¢ VADCG purchases Collins Model 32RS-1C SSB 
to replace HF beacon tranceiver on 14.076 MHz. 

¢ VADCG obtained VE7PKT call from DOC. 

¢ Article on slowing TNC bit rate for HF packeting. 


Issue 3, November 1980 


° VADCG purchases Altair 8800 S-100 mainframe, 
orders Z80 CPU card and 32K Expandoram 
memory card. This will be used with a VADCG 
designed $100 Station Node Controller board, to 
become part of a permanent station node. 


¢ Article describing implementation of serial TTL 
level interface instead of RS-232 driver/receivers. 

* Article describing RS-232 and the VADCG TNC, 
and various ways to connect to peripheral devices. 


e VE7APU describes bug fix for link buffer full 
problem. 
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Issue 4, March 1981 


Hank Magnuski, KA6M operating packet beacon 
and repeater in San Francisco, using techniques 
similar to VADCG. KA6M/R Packet Repeater 
Info Sheet in this issue, describing their claims. 
World first? This was an all digital simplex ama- 
teur packet radio repeater on 146.580 MHz in 
Menlo Park, CA. System was Z80 based, Pascal 
software, using Western Digital WD1933 HDLC 
chip. 
Hamilton, (Ontario) and Area Packet Network 
group (HAPN) formed and were already using 
VADCG TNCs. 


VADCG going formal. Meeting chairman John 
Spraggs, WE7ADE, Secretary Don Oliver, 
VE7AOG. 

145.65 MHz VE7PKT gets echo capability in 
addition to beacon function. Bob Livingston, 
VE7CYB, designs a 300 baud 103 autoanswer 
modem as gateway between telephone system and 
packet radio network. John Spraggs, using 
AppleII and VE7CYB prototype 103 modem 
accessed VE7PKT thru telephone! Another first! 
1200 baud packet radio modem PCB being 
designed. 

Wirewrapped $100 Z80 compatible HDLC station 
node card tested. 

Doug, VE7APU, published "Proposed Design for 
a High Speed, Low Cost, 220 MHz FSK Tran- 
ceiver for Amateur Digital Communications". 


Several pages of VADCG TNC software 
enchancements and hardware mods made by 
HAPN packeteers. 


"SDLC and Bit Oriented Protocols" article. 


Issue 5, July 1981 
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Several software change bulletins for revising 
VADCG TNCs. 

Report of World’s First satellite packet exchanges 
between Ottawa packet radio group, and VADCG, 
using Anik-B geostationary satellite. WVADCG 
TNCs at both ends. Project was jointly sponsored 
by CRRL and CARF. 


1200 baud radio board populated and tested. 
Attended Maple Ridge Hamfest again this year. 


Vulcan Computer Systems donates Apple II for 
Packet/BBS gateway use. 


More TNC PCBs ordered, high demand in San 
Francisco Bay area. 


AMRAD proposes HF Packet Radio Network. 
Discussion between Doug VE7APU and Paul 
Rinaldo, W4RI. 

VE7ADE describes AppleII BBS plan and Echo 
killer patch. 

Reports of VADCG TNCs running in Canada, 
Washington State, Washington DC area, San 
Francisco, CA, and other US locations. One even 
sent to Germany. 


Issue 6, December, 1981 


TIP and LIP software source listings in this issue. 


VE7APU article on “Network Architecture for a 
Wide Spread Amateur Digital Communications 
Network" 


1200 baud radio modem boards at manufacturers, 
will be available in 2 months. Bob, VE7CYB, 
will assemble and test 50 of 100 boards ordered. 
Setup required. 


Issue 7, September, 1982 


Announcements of TAPR in Tucson, and SLAPR 
in St. Louis, developing own hardware, will use 
compatible protocol to VADCG’s. 


Discussion on CBBS, RTTY and telephone gate- 
ways. 

Bob, VE7CYB, has been developing an HF packet 
radio modem, using digital filters, experimenting 
with self correcting error codes, and HF packet 
protocols. 


Doug VE7APU, now in Toronto, continuing 
software development. 


Jim Swetlikoe, VK2BVD (VE7ABH) starts up 
Australian packet group, using VADCG hardware 
in Sydney. 

Calgary ARC RTTY group interested in VADCG 
system. 


Article describing AMTOR on HF in United 
Kingdom, West Germany, Australia and US hams 
with special permits. ARRL petitioning FCC to 
allow US use. 

Article describing theory and design of VADCG 
1200 baud radio modem, uses Exar 2206/2211 
chips, schematic included in this issue. Boards 
ready. Being assembled and tested. 


Issue 8, October, 1983 

(This was a first in itself! A combined HAPN and 
VADCG newsletter "I-FRAME de VE3PKT" and "The 
Packet") 


the ‘packet’, Issue 10, September 1985 


e  VADCG reorganizing, VE7APU moving back to 
Vancouver. 


¢ HAPN executive changes. 


¢ Report on Hamilton-Toronto and Southern 
Ontario packet activity. New York state starts 
weekly packet net on 145.65 MHz. 


¢ VE7APU reports on 2nd annual ARRL Radio 
Computer Networking Conference. 


e John, VE3NEC, describes interfacing TNC to his 
Radio Shack Model III & IV. 


¢ Tips from HAPN on bringing up your packet 
radio station. 

¢ Report on Packet Radio in Australia. First 2 sta- 
tions up as beacons on Feb 20/83 (VK2KFJ & 
VK2ZXQ). VK2BVD up 1 week later. VE3DVV 
repeater software used. VK2ZXQ sets up RCP/M 
system May 21/83 using local and VE3MWM 
software. "Sydney Amateur Digital Communica- 
tions Group (SADCG)” now a formal entity. 


¢ Report on Rochester, NY, Hamfest and packet 
demos there. 

¢ Report on repeater linking project between 
Toronto- Hamilton area and upstate New York 
(Rochester) hams. List of digital repeater sites in 
Ontario and New York. 

¢ TNC Engineering Changes - debounced TRAP, 
RESET; status indicator LED, real time clock 
mod. 


e List of TNC’ address assignments’ in 
Toronto/Hamilton 


¢ John Vanden Berg, VE3DVV, "RPT13 repeater 
software” described. 

¢ Jack Botner, VE3LNY describes his IBM-PC 
packet radio /O card using 8273 HDLC chip.Host 
programs for IBM-PC based on Vancouver proto- 
col. "Theory and Operation.” article. AMRAD 
TIP. VADCG donates TNC to HAPN for their 
2nd repeater. 


Issue 9, October 1984 


¢ Another World First! The original Vancouver 
Protocol has been successfully used to communi- 
cate between Canada and Australia via the Oscar 
non-geosynchronous _ satellite. Stewart Beal, 
VE3MWM and John Tanner, VK2ZXQ_ both 
using VADCG TNCs. 

* Doug Lockhart VE7APU recommends X.3 to 
ARRL Ad Hoc Digital Packet Radio Committee. 
Already planned for inclusion in next VADCG 
TNC software release known as V2. 
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e V-2 software available on 2732 EPROMs or 8" 
CP/M disc. 

e V-2 protocol requires some minor hardware mods 
to TNC to increase memory space. Complete 
hardware modification is described. 

e Announcement and publication of "V-2, A New 
Vancouver Protocol". Complete technical 
specifications by Doug Lockhart, VE7APU. 

This ISSUE 10 will set the scene for the next 
five years of the Packet by going online. 


CP/M TIP HOST PROGRAM 
X3-HOST.ASM 
dated: march 4, 1985 


J.C.Vanden Berg VE3DVV 


THIS IS THE HOST COMPUTER SOURCE 
CODE FOR A CP/M SYSTEM TO INTERFACE TO 
A VADCG TERMINAL CONTROLLER WITH 
X.3/X.28. 


PURPOSE: 


X3-HOST.ASM is a program written by me for 
a CP/M system based on the 8080, 8085 or Z80 pro- 
cessor tO communicate with a TNC (terminal node 
controller) using the X3/28 PROTOCOL as defined 
by OSI. 


REQUIREMENTS 


e ACP/M SYSTEM RUNNING VERSION 2.0 OR 
HIGHER. 


¢ ACP/M SIZE OF 16K OR BIGGER 


¢ A RS232 SERIAL PORT WITH HANDSHAKE 
LINES 


This implementation uses CTS/RTS handshak- 
ing and requires DSR from the TNC to be active. In 
addition it uses the CD line from the TNC to deter- 
mine the state of the TNC (linked or unlinked). 
Assuming the computer is configured as DTE (data 
terminal equipment) and the TNC as DCE (data com- 
munication equipment) we would be using the follow- 
ing RS232 lines as seen at the host computer. 

TXD (transmit data) 
RXD (receive data) 
RTS (request to send) 
CTS (clear to send) 
DSR (data set ready) 
GND (signal) 

CD (carrier detect) 
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20 DTR (data terminal ready) 


Since the X.3 protocol also supports many dif- 
ferent options concerning handshaking, data transfer 
etc. it is important to have the proper parameters set. 
The recommended parameters you find under 
RECOMMENDED PARAMETERS SETTINGS. I 
recommend that you have these parameters come up 
by default, so you don’t have to remember them. 

My implementation uses 4800 baud, simplex, 
no parity, rts/cts handshaking and block transfers of 
data from the TNC. Data to the TNC is sent as blocks 
or char by char. The program consist of the following 
modules : 

X3-HOST.ASM 
main module 
SEQIO.LIB 
sequential i/o library ( supplied with MAC ) 
MYSUB.LIB 
my own library, containing handy subrou- 
tines 
IOPACKET.LIB 
customizes library for different systems 
Only IOPACKET.LIB needs to be modified for dif- 
ferent systems, since it contains user dependent infor- 
mation, such as callsign, specifics of the RS232 
hardware, optional beacon and test messages etc. 


After customizing above library you should use 


the DIGITAL RESEARCH ASSEMBLER MAC to 
generate the source code. To do this you type: 


MAC X3-HOST $PZ 


The switch $PZ may be omitted, in which case it also 
generates a list file. After this you look for the file 
X3-HOST.HEX file and convert this to a COM file. 
Type: 

LOAD X3-HOST 


This will leave you the file X3-HOST.COM , which is 
your object code. Now type: 


X3-HOST 


At this time the program will check for the proper 
version of CP/M (2.0 or higher) and test for DSR 
from the TNC. If all is well it will show you a logo 
and you will be monitoring the packet channel. Make 
sure your TNC is powered up and running the proper 
protocol. (ex: V2 with TIPTT2 software). To send a 
message just type the message and hit CR to send it 
out. 
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COMMANDS: 


There are two types of commands, HOST com- 
mands (executed in the host computer) and TNC com- 
mands (executed in the TNC). There is a help menu 
in the host computer to show you the HOST com- 
mands. All commands (host and TNC) start with an 
escape character, followed by the command and 
parameters (if required). To get the help screen you 
type <esc>HELP, or <esc>??". Only the first two 
characters are being used for command decoding. If 
the command is not found in the host command table 
than the command will be passed on to the TNC tip. 
The TNC will send an error message back if the com- 
mand is invalid. For a list of the TNC commands see 
the file "X3/X28.DOC". 


Raaanaanankaaak < LOCAL COMMAND MENU > See eaneeeaanatan 
<esc>HE or <esc>?? this help menu 1 
<esc>RF rx file using protocol 2 
<esc>SF filename tx file using protocol 3 
<esc>RF filename [/A])(/B] rx a file, no protocol 4 
<eso>RF ([(/T] erminate rx a file 5 
<esc>SF filename [/A] (/B) (/P] [/E] 
tx a file, no protocol 6 
7 
8 
9 
10 


<esc>SF ([(/T] terminate tx a file 


<esc>VE display program version 
<esc>ss display system status 
<esc>TE send test message 

<esc>Bl turn on beacon 1 1l 
<esc>B2 turn on beacon 2 12 


<esc>EX or <esc>Qu exit to DOS 13 


The second and third commands are used for 
file transfers using the SF/RF protocol as defined by 
VE3LNY (see file: "FILEXFER.DOC" for details on 
protocol). The protocol checks for disk space before 
going ahead with the transfer. To abort a file transfer 
just hit the escape character. The protocol works for 
both ascii and binary files. 


The fourth command opens a log file for 
receive (ascii or binary). If ascii is selected the file 
will be closed when a eof (ctrl-z) is encountered. If 
/8 binary is specified the file has to be closed manu- 
ally with <esc>RF /T". 


The sixth command sends a file ( /A for ascii, 
/8 for binary, /P for parameters, /E for local echo). 
There is no transfer protocol with the receiving end. 
The parameter option lets you load into the TNC a 
different set of parameters, or read the current param- 
eters. The data here is sent to the TIP and does not go 
over the air. If your default parameters are cor rect 
you would not need to use this option. To abort above 
command use the /T option. 


The eighth command displays the host software 
version. 

The ninth command displays the system status 
such as: 
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LINKED/UNLINKED 

OPEN FILES 

BEACON ENABLED/DISABLED 
NUMBER OF BYTES FREE ON DISKS 


the command also logs in a new disk for r/w if you 
change disks. 

The tenth command sends a test message as 
defined by the user in IOPACKET.LIB 

The eleventh command sends a beacon message 
as defined by the user. 

The twelfth command sends a beacon message 
as defined by the user. 

The last command drops RTS so no further data 
is send from the TNC to the host than closes any open 
files and terminates the program. The TNC keeps on 
monitoring the channel till its receive buffer is filled 
up. 


RECOMMENDED PARAMETER SETTINGS 


PAR <01:27> PAR <20:00> 
PAR <02:00> PAR <21:02> 
PAR <03:00> PAR <22:00> 
PAR <04:01> PAR <23:80> 
PAR <05:04> PAR <24:16> 
PAR <06:01> PAR <25:05> 
PAR <07:00> PAR <26:10> 
PAR <08:00> PAR <27:00> 
PAR <09:00> PAR <28:01> 
PAR <10:00> PAR <29:00> 
PAR <11:13> PAR <30:00> 
PAR <12:02> PAR <31:00> 
PAR <13:00> PAR <32:01> 
PAR <14:00> PAR <33:120> 
PAR <15:00> PAR <34:00> 
PAR <16:08> PAR <35:00> 
PAR <17:21> PAR <36:00> 
PAR <18:18> PAR <37:00> 
PAR <19:00> PAR <38:00> 
PAR <20:00> PAR <39:01> 
PAR <21:02> PAR <40:255> 
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File Transfer Protocol 
for Packet Radio 


Jack Botner, VESLNY 
May, 1985 


When transferring files from one packet station 
to another, it is very convenient to have an automated 
process to perform the transfer. This is particularly 
useful when a binary file is being sent, since it is 
difficult to tell where the data begins and ends, and 
harder still to edit the received file if extraneous data 
happens to get included in the file. 


I have written a set of file transfer programs 
that run in the IBM PC for transferring files automati- 
cally. These programs, named SF and RF, implement 
a simple file transfer protocol that could be incor- 
porated in any microcomputer used on packet radio. 
The protocol includes the following features: 


1. The name and size of the file is sent to the 
receiver, so he knows what file is coming and 
how much space is required. 


2. The sender or receiver can interrupt the transfer 
at any time, by manual intervention at the key- 
board. 


3. No extraneous data can get accidentally included 
in the file. 

The process works in three stages: synchroniza- 
tion, intent, and file transfer. The synchronization 
step is necessary because packet radio as currently 
implemented with the TNC is byte-oriented from the 
point of view of the host (or terminal), and it is neces- 
sary to send distinct blocks during the file transfer. 
The intent step sends the file name and size to the 
receiver, who then accepts or rejects the transfer. 
Then, in the last step, the data is transferred. 


The data that pass between SF and RF is always 
in the form of blocks. The block is defined as one 
byte of flags and one byte length, followed by a vari- 
able number of data bytes. The flag and length are 
known as the header. The header length always 
specifies the number of data bytes in the block. The 
flags specify the purpose of the block. The following 
flag bytes have been defined: 

0’: +Synchronization request from SF. 
’1’:_ Synchronization response from RF. 
2’: +Intent message from SF. 

’3’: Positive response from RF. 

’4’: Reception complete from RF. 


5’: ABORT request from either SF or RF. 
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’°6’: Block of data from SF. 
»7’: LAST block of data from SF. 


Synchronization procedure 


It is uncertain whether SF or RF will begin exe- 
cution first. Therefore, the convention was chosen 
that SF sends the first message, and RF waits for it 
and sends the response. When SF begins execution, it 
sends a 4 byte block, consisting of flag ’0’, length 2 
(binary), and the data "SF". If no response is 
received, the message is resent at 15 second intervals 
until the correct response is received, or the sender 
gives up and interrupts the program. (I have chosen 
the use of the "Esc" key for interrupting the program). 

When RF begins execution, it waits for the syn- 
chronization message from SF. Other data may be 
received, but is ignored (but may be displayed on the 
screen). When the above 4 bytes is received, RF 
sends a 4 byte block consisting of the flag ’1’, length 
2 (binary), and the data "RF". RF then assumes it is 
synchronized with SF and goes to the intent message 
stage. 


SF should eventually receive the synchroniza- 
tion acknowledgment from RF. Other data received 
in the meantime is ignored (but may be displayed on 
the screen). Once the message is received, SF 
assumes it is synchronized with RF and goes to the 
intent message stage. 

It is useful during the synchronization step to 
display received data on the screen. For instance, if 
one station starts SF or RF, and the other station sends 
the message “wait, the phone just rang", the first sta- 
tion can see why the file transfer did not start as 
expected. However when _ synchronization is 
achieved, both programs should stop displaying 
received data on the screen. 


Intent Message procedure: 


SF builds an intent message, consisting of the 
flag ’2’, the length of the data, and data consisting of 
the file name, one or more blanks, and the file size in 
ASCII digits. The filename may be obtained from the 
sender from a command line parameter or by prompt- 
ing. The file size should be obtained from the com- 
puter, and expressed in bytes. The message is then 
sent to RF, and SF waits for a response. 

The file size is not available in some computers. 
If this is the case, a size of zero should be sent as the 
file size; this will be understood as meaning "size not 
available”. 

In the meantime, RF is waiting for the intent 
message. When it is received, RF must take the 
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appropriate steps to open a file to receive the data. If 
a non-zero file size has been received, RF can deter- 
mine if it has enough space to receive the file, and 
perform any desired action to ensure the file transfer 
will be successful. For example, RF can see if a 
duplicate file name exists and ask the operator if it 
should be overwritten. Then, RF must send either a 
positive response (flag ’S’, length 2, data "RF") back 
to SF. If an abort is sent, RF is finished and the pro- 
gram may end. Otherwise it goes to the data transfer 
stage. 


SF waits for the intent message acknowledg- 
ment from RF. When it is received, SF either ter- 
minates, if an abort is received, or begins sending the 
data. 


Data Transfer procedure: 


SF builds data blocks and sends them to RF. 
Each block consists of the flag ’6’ (or ’7’ for the last 
block), the data length, and O or more bytes of data. 
SF and RF use the limit of 62 bytes of data for each 
block, but this value is arbitrary. No response is 
expected from RF unless the receiver wants to inter- 
rupt the transfer with an abort request. Therefore, SF 
should be watching for incoming abort requests. 


RF receives each block and stores the data in 
the file. When a flag of ’7’ is received, the transfer is 
complete and the file should be closed and the pro- 
gram ended. ’7’ may or may not contain data, but it 
must exist to end the transfer. If something goes 
wrong, the receiver can send an abort block to stop 
SF. In addition, RF should look for an abort block on 
input, and if received, finish up its processing. 

SF and RF should not display the transferred 
data on the screen, since, in the case of binary files, it 
is meaningless on the display. In addition, various 
control characters may occur in binary files and may 
cause unexpected effects on the screen. It is better to 
keep a count of the bytes sent/received and write 
periodic status messages on the screen (i.e. 2433 
bytes sent, 1255 bytes remain) so that 
the user is kept informed of the progress of the 
transfer. 


End of Transfer procedure: 


Since SF effectively finishes sending the data 
well before RF has received it all, a method is desir- 
able to keep RF from ending until all the data has 
been received by RF. After all the data has been sent, 
SF waits for a “reception complete" message from 
RF, then terminates. RF simply needs to send the 
"reception complete" message to SF when the last 
block has been received. 
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General: 


It may also be useful for SF and RF to monitor 
the status of the session, i.e. if the TNC is connected 
or not. If this is possible in your host, then you can 
terminate SF or RF if the station you are connected to 
inadvertently disconnects in the middle of a transfer. 
Also keeping a timeout count during waits for sends 
and receives is very useful, in case something goes 
wrong with the communications link. After, say, 5 
minutes of no activity, the program can send an abort 
and terminate. 


The following is a summary of the block for- 
mats: 


USE FLAG LENGTH DATA 
Synch. request "or 2 “sF° 
Synch. response a 2 “RF* 
Intent request *2° +data filename blank filesize (ascii) 
Intent response oa 2 “RF 
Reception complete ‘4’ 2 “RF° 
Abort *3*. 2 "SF" or “RF® 
Data we" data data from SF. 
Last data "7° data data from SF. 
Packet Radio News 
from Compuserve HOM-11 
May 7, 1985 
W3IWI COMMENTS: 


The following from the W3IWI PBBS was 
relayed to other linked PBBS’s in the MAPRC (Mid- 
Atlantic Packet Radio Council) area. It is forwarded 
via DRNET since some of you in other areas might 
find it useful. Comments represent my personal 
views/understanding/detective work and should not be 
construed as official statements by anybody! No 
group/organization/firm can be held liable for any 
errors of omission/commision I may have made in the 
following. 


73 de Tom, W3IWI 


Packet Radio News de W3IWI — 28 April 


I just returned from the Dayton Hamvention 
and want to let you know of all the exciting develop- 
ments in Packet Radio. First, let’s start by describing 
the new products seen there: 


Heathkit: The TAPR-clone HD4040 was very 
prominent. I was told that Heath’s initial production 
run of 4040’s was 500 units and representing a 3 
month sales forecast — since their catalog came out 
earlier in April, the had delivered about 450 units, and 
had only 50 for sale at Dayton. The 50 were sold out 
before the weekend was over. Heath showed their 
new add-on status indicator box (which will also work 
with TAPR units, since the TAPR TNC-I and 
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HD4040 are identical, and which will work with AEA 
units if the parallel port chip is installed for the same 
reason) — this little 2” cube indicates connect status, 
buffer status and even beeps when someone connects 
with you. One Heathkit rep told me he is trying to get 
Heath to make their metal cabinets to be available for 
those TAPR owners that still are using a cardboard 
box or piece of plywood. 

Kantronics: Kantronics showed their new 
"Packet Communicator" TNC. This 2"x6"x8" box 
looks like a smartmodem and lists for $350 (available 
with discounts) — pictures can be seen in the most 
recent amateur magazines. The innards have some- 
thing like 7 chips, and uses a 6803 processor. The 
code is adapted from TAPR’s TNC-I code with 
several changes. The low-level routines that generate 
HDLC format and NRZI data are done in software 
rather than using a hardware HDLC controller chip. 
The async link to the user’s terminal makes use of the 
UART built into the 6803; since everything is inter- 
rupt driven, this software approach does not seem to 
suffer from the ills of the GLB — i.e. not being able 
to service both the "radio" and the terminal at the 
same time. However, the software HDLC generation 
seems to be the reason that the maximum baud rate 
"on-the-air” is 1200 (supported speeds are 300, 400, 
600 and 1200 baud). Since the high-level code is a 
clone of TAPR’s, a TAPR user can step up to a Kan- 
tronics unit and operate it with complete familiarity. 
The Kantronics unit has a built-in modem using the 
single-chip Am 7910 “world” modem which offers 
both 103A (for HF use) and 202A (for VHF use at 
1200 baud). It uses a 5-pin DIN connector for the 
radio interface, and operates from an external +12 
VDC supply thru a 3.5 mm jap-standard power con- 
nector. Kantronics Advertisement promises special 
packet terminal ("Pac-Term") software for many 
popular computers in the near future; since the Kan- 
tronics user interface is identical to 
TAPR/Heath/AEA, it would seem to me that this 
software should be usable with with any of the 
TAPR-based TNC’s. 


HAL: The main-line RTTY manufacturer from 
Illinois introduced their TAPR-clone (intended pri- 
marily for commercial applications) in a beautiful 
3.5" rack-mounted cabinet and priced at about $1000. 


TAPR TNC-II: The non-profit TAPR group 
made the big hit of the show by introducing their new 
TNC-II (sometimes called “tiny-TNC") controller. 
Physically, it looks almost identical to the new Kan- 
tronics unit (not surprising, since the aluminum extru- 
sion used as a cabinet comes from the same manufac- 
turer that supplies Kantronics) except that it is slightly 
longer (about 9"); interface connections are also 
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essentially identical to the Kantronics, including a 5- 
pin DIN plug for the radio interface. 


TAPR’s new gem employs a Z80 cpu 
(hardware designed by AD7I) with the TNC software 
written in native Z80 assembly code (by N2WX); the 
operating software consumes about 12k bytes of 
ROM space and the user interface is essentially ident- 
ical to the older TNC-I (a.k.a. Heath HD4040, a.k.a. 
AEA PKT-1). Memory on the TNC-1 consists of 3 
byte-wide sockets with the RAM being CMOS with 
battery backup (replacing the NOVRAM on TNC-I). 
HDLC generation uses one half of a Z80-SIO chip, 
and the async terminal uses the other half. The NRZI 
encoding/decoding and clock recovery is done with a 
DPLL implemented as a finite-state-machine with a 
2716 EPROM and ’LS373 byte-wide latch. The 
modem is a carbon copy of the XR2211/XR2206 
design in TNC-I; The TNC-II also uses the same 20- 
pin external modem connector. Power requirements 
are +12 VDC only, with negative voltages for the 
RS232 terminal interface being derived from a small 
on-board DC/DC converter (a la the AEA PKT-1). 
The power consumption is < 3 watts when NMOS 
chips are used and falls to about 1.5 watts when the 
board is populated with CMOS logic. 


It is my understanding that the functional differ- 
ences from TNC-I are as follows: 


¢ The support of VADGC V.1 protocol has been 
dropped. 

¢ TNC-I’s NOVRAM had two “banks” which could 
contain different set-up parameters; TNC-II has 
only one “bank” in its battery powered CMOS 
RAM. 


e TNC-I had an initial “autobaud" routine for setting 
the terminal baud rate during cold restarts; TNC- 
II’s terminal baud rate is set with a dip rocker 
switch on the rear panel. 


* TNC-I had up to 16 possible HDLC baud rates 
settable under software control, while TNC-2 has 
8 baud rates set by rocker switches (unless an 
external clock is provided). TNC-II’s maximum 
baud rate is 9600 baud with the internal baud rate 
clock (although 56 kbaud should be possible with 
an external clock). 

¢ The parallel I/O port (usually not used except by 
status indicators like the new Heath box men- 
tioned earlier) is not supported. However, front 
panels LED’s on TNC-II show "connected" and 
“TNC has unacknowledged packets" status func- 
tions. 

* TNC-II firmware supports AX.25  Rev.2 
specifications. Rev.2 firmware for TNC-I won’t 
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be available ’till summer. 


- A number of new functions have been added, 
which will be described in later reports after I get 
my hands on a real, live TNC-II. 


TAPR indicates that the initial production batch 
of 300 units will be available sometime this summer. 
So far, about 8 units have been fabricated from a 
"Beta" test batch of 25; the other 17 "Beta" units will 
be making it into the field in early May. In the 
MAPRC area there will be two of the initial test units 
— WBA4IJFI to test compliance with AX.25 Rev.2 and 
W3IWI to test compatibility with applications like 
WORLI PBBS’s and_ suitability for certain 
AMSATI/PACSAT related tasks. TAPR will not take 
orders for the TNC-II until it is ready to make the ini- 
tial production run of 300 units. 


Oh yes — VERY IMPORTANT — The price 
announced for TNC-II is $185 (in kit form) including 
the cabinet! 


Other commercial notes: Neither AEA nor GLB 
seemed to have anything new. I couldn’t believe how 
many people were offering IBM-PC clones in quasi- 
kit form. New MPI 8" single-sided disk drives were 
priced about $25 and SA-455 1/2 height 5" drives 
were going for $85. 150nsec 4164’s were available at 
$0.90 - $1.00. Switching power supplies of every 
possible ilk were found in abundance. It seems easier 
to buy computer goodies at hamfests these days than 
RF hardware! 


KONG 9600 Baud Modems: Steve Goode 
gave another presentation on his 9600 baud hardware 
at one of the Dayton forums and his prototypes were 
running in the TAPR booth. TAPR has produced art- 
work for the modem boards and the initial verification 
batch of 5 boards will be available available for Steve 
to evaluate next week. After PCB verification, an ini- 
tial batch of about 100 boards will be made (presum- 
ably in June) to act as a "seed" for network tests else- 
where. The KONG design assumes a radio with direct 
FM capability (i.e. a varactor in the xtal oscillator) on 
xmit, a rcvr with about 12 kHz bandwidth (typical FM 
radio) with a direct connection to the discriminator 
output. The interface to the TNC is via a ribbon cable 
to the 20 pin dip header "external modem" connector 
on TNC-I, TNC-II, AEA or HD4040 TNC’s. 


TAPR’s clearance sale: Early in the morning 
on Monday, 4/22 the word went out that TAPR 
wanted to clear the decks on it’s remain ing inventory 
of about 200 TNC-I kits and 100 cabinet kits. The 
news went out from Tucson by electronic mail thru 
DRNET, from whence various individuals spread the 
news via PBBS’s, CompuServe, UNIX Usenet, word- 
of-mouth, etc. By Tuesday, everyone was amazed to 
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find that the inventory had dropped to ZERO! As best 
I can determine, my posting the news on the 
MAPRC-area PBBS’s (W3IWI, KS3Q, WB2MNF, 
AK3P) led to 30-40 units being ordered by people in 
this area. TAPR has no more TNC-I’s left and does 
not plan to make any more. If you need a TNC 
between now and the time that the TNC-II becomes 
available later this year, your source will have to be 
Heath, AEA, Kantronics, HAL, Ashby or GLB 
(unless you can con one out of somebody who 
ordered an extra TNC-I). 


Other news: The packet forums were very well 
attended, with 300-400 in the audience for most ses- 
sions (other commitments forced me to miss many of 
them, so I’m not a good source of details — perhaps 
someone else can report). Friday at the AMSAT 
forum, K8MU, NK6K and I told about PACSAT 
status. Saturday nite (instead of eating rubber chicken 
at the banquet and listening to K2ORS), 50-60 of us 
had an informal meeting at a local sandwich shop. 
MAPRC attendees included WB4JFI, WB2MNF, 
KC2TN, K3TS, KA9Q and W3IWI. We had a 
chance to chat with the Pittsburgers about the impend- 
ing Blue Knob digipeater. A lot of discussion went 
on about linking, level 3 and BBS’s. It was good to 
meet our counterparts from elsewhere to exchange 
notes. 


73, Tom 


A Letter from W4RI 
July 12, 1985 


To: Ad Hoc Committee on Amateur Radio Digital 
Communications 


Subject: Networking 


It seems to me that we are progressing at a 
snail’s pace with networking. There may be 10,000 
packet users by this time next year. If all they have is 
level 2, how long will they be happy — particularly if 
they have some idea of packet’s potential? 


Last September, we agreed to do a number of 
things to get network experimentation going. A 
number of foundational things such as the FAD board 
and dual-port digipeater software have been accom- 
plished. 

Are we all looking to Terry and Phil to solve 
this for us? If that’s the best plan, then what can the 
rest of us do to help them concentrate on networking 
and shun all other ill-conceived pastimes (computers, 
women, etc.)? 
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Is it time that we identified other possible con- 
tributors to the process? Who? How? 


Please let me know by electronic or physical 
mail what I or anyone else can do to move things 
along a little faster. Until I get a handle on how fast 
things are moving, or can move, it does not appear to 
be productive to set the next Committee meeting date. 


73, 


Paul L. Rinaldo, W4RI 
Chairman 


TAPR DUMPS TNCS 
ON UNSUSPECTING USERS 


In February of 1985, Lyle Johnson, the 
president of TAPR wrote, "And to set a rumor aside, 
TAPR has indeed sold non-exclusive commercial 
rights to its TNC hardware and software — to more 
than a few companies. But TAPR will continue to 
make the kit available: frankly, it is our source of 
funding for further research, development and infor- 
mation dissemination.” After receiving this promise, 
many were surprised when only two months later, in 
April, TAPR had a close-out sale announcing that it 
would no longer make the kit available. This wasn’t 
the only surprise. A few days later, after TAPR had 
sold out their entire inventory of nearly 200 TNC kits 
and 100 cabinets it was announced that TAPR was 
going to be producing a TNC based on a different 
microprocessor — the Z-80. This plan was kept a 
secret and only announced after the old TNCs had 
been sold, denying purchasers the opportunity of 
making purchasing decisions with all the facts at 
hand. I wonder what has become of old-fashioned 
integrity? I am sure there will be a lot of bafflegab to 
explain this stuff away. 

Pete Eaton, the executive vice-president of 
TAPR has explained why it was done like this, and I 
quote, "We had most of TAPR’s money tied up in kit 
parts for the old unit. If the word on the new unit 
leaked out and sales dropped because everyone 
wanted the new cheaper one, TAPR would go broke, 
belly up. Now maybe that wouldn’t have happened, 
maybe sales would not have dropped. We were not 
willing to take the chance.” 

Satisfied? A good reason to sacrifice integrity? 
Well this does not really explain what Lyle Johnson 
wrote on March 19, about a month before the sale, 
"We are now backordered 30 deep on TNCs. When 
we have some, we’ll see you get some!!!" If they are 
back ordered, how would the leaking of word on the 
new TNC cause TAPR to go broke? I don’t know 
because TAPR keeps details of its finances secret. 
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If the TAPR executives expected sales of the 
6809 based TNCs to drop precipitously as stated 
above, they must have thought it was pretty slick to 
sell commercial rights to ‘more than a few’ com- 
panies while secretly developing the new TNC. 
Where is respect for the user group or for the com- 
panies and individuals that TAPR is doing business 
with? Is integrity something that can be dispensed 
with for the greater glory of TAPR? 


COMPUTER COMMUNICATION 
PROTOCOLS 


David Bowman 


Introduction 


A computer communication protocol is a set of 
conventions, defined and agreed upon before com- 
munication begins, which is designed to facilitate 
communication between distinct computer processes. 
A protocol is necessary for the orderly exchange of 
information between computer processes. 


Protocols 


Typically, protocols consist of three 
separate but related parts: 


Syntax 

The syntax of a protocol relates to the 
physical structure of the information to be 
transmitted between processes. Depending 
upon the level at which a protocol operates, 
syntactic specifications describe items such as 
electrical signal levels or the position of various 
fields (i.e. addresses, control information, user 
data) within the blocks of information 
exchanged between the communication 
processes. 


Timing 


Protocol timing includes issues such as 
the actual bit rates associated with communica- 
tion, the minimum time interval allowed 
between the transmission of blocks of data, and 
speed matching between processes which han- 
dle communicated information at different 
rates. 


Semantics 


The semantics of a protocol interpret the 
data communicated between processes. For 
example, certain protocols may define specific 
message types or information fields within mes- 
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sages which control future communication, i.e. 
a message may be communicated from one pro- 
cess to another indicating that an error was 
detected in a previously received block of data, 
and that the block of data should be retransmit- 
ted. 


The ISO-OSI Reference Model 


To ease discussion of computer communication 
protocols, the International Standards Organisation 
(ISO) has produced an abstract model of computer 
communications, called Open Systems Interconnec- 
tion (OSI) Reference Model (RM). The RM was ori- 
ginally produced to describe communications in the 
wide area network (WAN) long distance telephone 
environment but it is applicable to local networks and 
Packet Radio networks as well. The model provides a 
conceptual framework within which the features and 
facilities of any system can be discussed. It was not, 
however, intended to provide guidelines and design 
tules for system implementors and users. 


A basic understanding of the ISO-OSI Refer- 
ence Model is vital to an understanding of the issues 
involved in designing and using computer communi- 
cation protocols. Additionally, because most of the 
terminology currently being used in Packet Radio 
literature with regard to protocols V-2 and AX.25 is 
derived from the ISO Model, this discussion of the 
RM should help designers and implementors in deal- 
ing with the wealth of technical literature available in 
this expanding field. 


Overview of the ISO-OSI RM 


The key concept of the ISO-OSI RM is the pro- 
tocol layer. A layer is a level of abstraction within the 
process of computer communication. Two interfaces 
are associated with any layer; for example, associated 
with layer N are the interfaces to the next higher level 
layer (layer N+1) and the next lower level layer (layer 
N-1). The designer may assume that layer N provides 
a well-defined class of services and an interface to 
layer N+1. Layer N is, in tum, implemented using 
services provided through the interface to layer N-1 
and subsequent lower layers within the model. There 
is not a strict ordering among the layers, in the sense 
that abstractions at higher levels may not require the 
use of all abstractions at lower levels. Further, the 
classification of layers may depend upon one’s 
viewpoint. A particular designer’s view of the system 
may cause certain layers to be transparent, or what 
might be a complete structure of layers may be 
viewed (from higher layers) as simply a single layer 
and its interface. Layers are only allowed to interact 
through layer interfaces. Communication takes place 
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within the model between peer levels, that is, between 
layers which exist at the same level on distinct net- 
work hosts. 


The basic concepts of layering and modular 
design has been highly touted (if not always prac- 
ticed) in software design circles for many years. 
Some of the reasons that one wants to view and 
design the system as a hierarchy of layered services 
are: 

1. Any facilities necessary to implement the func- 
tionality of a given layer can be made invisible 


to all other layers, thereby enforcing modular- — 


ity. 
2. Complex systems can be broken down into 
understandable sub-systems. 


3. The system can evolve in a simple fashion, 
because the facilities that implement a layer can 
be changed without impact on the other layers, 
just so long as the interface remains the same. 


4. Services offered at a particular level may share. 


or multiplex the services of lower levels. 


5. Alternative implementations which preserve the 
functionality and interfaces of a layer may be 
co-existent with the system. 


6. Layers can be extended, simplified or deleted at 
any time, based upon the need for services pro- 
vided by that layer. 


7. Each layer may be analyzed and tested indepen- 
dently of all other layers, and thus the system 
may be developed in a series of independent 
operations and verified layer by layer for 
correct operation. 


THE MODEL. 


The ISO-OSI RM is designed as a hierarchy of 
seven distinct protocol layers: 1) Physical; 2) Link; 3) 
Network; 4)Transport; 5) Session; 6) Presentation; 7) 
Application. 


The Physical layer 


This protocol layer is concerned with electrical 
and mechanical specifications, i.e., signal levels and 
connectors. The function performed by the physical 
layer is the transmission and reception of an unstruc- 
tured stream of bits over the network communication 
media. Examples of physical layer protocols include 
the common RS-232, RS-449, and CCITT X.21, as 
well as the proprietary connection _ strategies 
employed by a variety of manufacturers to allow con- 
nection to various local area networks. 
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The Link Layer 


The function performed by the link protocol 
layer (also called the data link layer) is the transmis- 
sion/ reception of a structured stream of bits over the 
network. Whereas the physical layer provides for the 
transmission of a raw bit stream, the data link layer 
provides the ability to sub-divide this bit stream into 
structured blocks of information commonly called 
frames. Frames are typically delimited by reserved 
bit patterns, reserved character sequences, or through 
the inclusion of an explicit bit or byte count within the 
frame. Data link protocols usually include some 
means of error detection, typically based upon a sim- 
ple checksum included at the end of the frame. 


The Network Layer 


The function of the Network Layer is to facili- 
tate the transmission/reception of a packet from a 
source node to a destination node within the network. 
In traditional point-to-point store-and-forward net- 
works, packets are typically passed from source to 
destination through a series of intermediate nodes, 


_and hence some strategy for routing a packet to its 


eventual destination must exist. This strategy is 
implemented within the network layer. 


Typically, within the local Amateur Radio 
network’s sphere, packet routing is not currently 
implemented due to the inherent "broadcast" nature of 
the network. Hence, in most packet radio software 
developed to date, the network layer is small or even 
totally empty! 


The Transport Layer 


The function of the transport layer is to provide 
for reliable end-to-end or host-to-host communication 
over the network. Two differing strategies have 
evolved to support this reliable communication, vir- 
tual circuits and datagrams. Datagrams are self- 
contained messages which include explicit source and 
destination addressing information and which are 
delivered reliably under control of transport layer pro- 
tocols. Virtual circuits allow logical rather than physi- 
cal connections to be established between source and 
destination and provide for a reliable data stream to 
be passed over the "circuit" from end-to-end. 


Virtual circuit based transport services have 
been the most widely used to date, and thus much of 
the machinery contained within the transport layer 
allows for the opening and closing of communication 
links, or "calls", between machines. Some observers 
feel that the dominance on virtual circuit protocols is 
a reflection of the difficulty involved in efficiently 
implementing a reliable datagram service on the 
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long-haul store-and-forward networks which were the 
impetus for the creation of the ISO-OSI RM, rather 
than any inherent advantage which they have over 
datagram protocols. It will typically be easier to 
implement a reliable datagram service within the con- 
strained environment of the packet radio network, and 
since the overhead associated with connection estab- 
lishment is reduced in datagram protocols, the growth 
of packet radio network technology may promote 
renewed interest in reliable datagram-based protocols 
within the transport layer. 


The Session Layer 


The function of the session layer is the manage- 
ment of end-to-end communication between 
processes running on network hosts. Typically, the 
session layer provides facilities to map logical process 
or port names (character strings) into network address 
information meaningful to the transport layer. The 
session layer manages interprocess communication 
within the network by opening, closing, and sending 
data over the transport layer virtual circuits, or by 
sending transport layer datagrams, or both, depending 
upon the facilities which are available at the transport 
layer. 


The Presentation Layer 


The function of the presentation layer is the 
_ transformation of data to be sent to or received from 
the session layer. For example, we might wish to use 
a text compression algorithm in order to minimize the 
amount of data to be sent through the network. Text 
would be compressed within the presentation layer of 
the transmitting host and expanded again in the 
presentation layer of the receiving host. Similarly, 
data encryption algorithms might be implemented at 
the presentation layer. Other examples of possible 
presentation layer functions include file transfer and 
virtual terminal protocols. 


The Application layer 


The function of the Application Layer is to pro- 
vide a variety of application-specific protocols to 
applications programs running in various hosts on the 
network. Typical application layer protocols might 
include services to facilitate information retrieval, 
electronic mail, text editing and conferencing. The 
variety of services provided at the applications layer 
is theoretically limited only by the variety of possible 
applications programs to be run in the network 
environment. However, virtually no standard applica- 
tion layer protocol exists today. 
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Conclusion 


A great deal of development effort is currently 
being devoted, worldwide, to the design of simple, 
flexible communication protocols for use in Amateur 
packet radio network systems. I was privileged to be 
at the conception stage and nine month’s later, the 
birth of VADCG here in Vancouver, Canada in 1979. 
We carefully modelled our software design around 
the conceptual architecture of the ISO-OSI Reference 
Model for six years. We even coined the terms TNC 
and SNC (Terminal and Station Node Controllers) 
and so we feel personally responsible for nurturing 
this six year old through the next six years and 
beyond. This tutorial is for those packeteers who 
need to understand these fundamental issues. 


NEW VANCOUVER TNC BOARD 


NEW FEATURES: 

¢ A full 64K Byte RAM/ROM memory capability 
for multiple protocols 

e Battery Backup for CMOS RAM 

¢ Onboard DC-DC power allows 12v DC operation 

e Four LEDs provide status indication 

e Independent serial and parallel interfaces 

¢ Dip switch input provides special configuration 
features 


¢ Optional direct TTL modem connection saving 
RS232 driver chips and power 


e Trap circuit allows monitor entry for debugging 
e Extended Baud rate generation for HF speeds. 


AVAILABILITY: 


The new Vancouver TNC is nearing successful com- 
pletion of the first production prototypes. Some have 
been delivered for testing. The first low volume pro- 
duction run will be shipped for Beta Testing as soon 
as possible. If you are interested in upgrading your 
present VADCG board, you may do so and save $$ 
since the most important chips remain the same. This 
board will permit continuing advances in both V2 and 
AX.25 software development. 


PRICE: 
To be announced. 
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